I would do Keys and rename saml keys to keys.
On Wed, 5 Jun 2019, 15:27 Marek Posolda, <mposolda(a)redhat.com> wrote:
Thanks everyone for the feedback. Created
as a follow-up JIRA on the
initial OIDC encryption support JIRA KEYCLOAK-6768
Not sure if it is better to have "OIDC Keys" or "Keys" . For the
clients, we have tab "SAML Keys" . On the other hand, at the realm level we
have tab called "Keys"... IMO any of those two is acceptable.
On 05/06/2019 14:31, Stian Thorgersen wrote:
+1 I also like the idea of OIDC keys, or perhaps it should just be called
+1 to separate pr as well
On Wed, 5 Jun 2019, 09:21 乗松隆志 / NORIMATSU，TAKASHI, <
> I think it is a good idea to have "OIDC keys" feature.
> When I wrote the PR for Support signature algorithm PS256/384/512 for
> tokens and request object (https://github.com/keycloak/keycloak/pull/5974
> I encountered this matter.
> "OIDC keys" feature might be beneficial for the clients using JWS Client
> Assertion (Signed JWT) as their authentication with signature algorithm
> other than RS256 (e.g. ES256).
> I think this "OIDC keys" feature be realized as the separate PR because
> the PR for ID Token Encryption is independent of how to load the client
> public key.
> Takashi Norimatsu
> Hitachi, Ltd.
> -----Original Message-----
> From: keycloak-dev-bounces(a)lists.jboss.org <
> keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
> Sent: Friday, May 31, 2019 4:31 PM
> To: keycloak-dev(a)lists.jboss.org
> Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and admin
> We have PR for introducing encryption support for OIDC ID Tokens. See 
> and .
> IMO The PR is great contribution and is quite complete. There is support
> for manage encryption keys through the REST API or through the OIDC client
> registration, which is probably sufficient for have the OIDC FAPI support
> happy. However one thing, which seems to be missing, is better admin
> console support for seeing and managing the encryption keys of the client.
> Regarding the admin console, the PR just introduces 2 new options for the
> client for choosing the algorithms for encryption of ID Tokens.
> For more details, admin console doesn't have support for "hardcode"
> client encryption key/certificate. It has support for downloading the key
> from the client's JWKS URL, but the JWKS URL is configured on the bit
> strange place. Right now, it is configured under tab "Credentials", then
> you need to choose "Signed-JWT" and then you can configure the JWKS URL.
> This was OK, when only point of JWKS URL was used just for signed-jwt
> client authentication. But now with adding the encrypted ID tokens support,
> this is not very appropriate place IMO. For example if you want to use
> encrypted ID Tokens together with traditional client authentication based
> on clientId/clientSecret, you shouldn't be required to go to "Credentials
> -> Signed JWT Authenticator" at all.
> So not sure, if we shoud do some small re-design of admin console now?
> For example, for SAML clients, there is tab "SAML Keys" where you can
> see/generate/import/export keys used for SAML. I can imagine something like
> that for OIDC clients too. We can introduce tab "OIDC Keys" or just
> . That will allow to have switch "Use JWKS URL" and then configure JWKS
> (optional) or alternatively the client keys used for SIG and ENC, which
> will be required just if "Use JWKS URL" is OFF similarly like it is
> currently in the "Credentials -> Signed JWT". Then in the tab
> -> Signed JWT", there will be just info that you need to configure JWKS URL
> or Signing key in the tab "Keys" - so no configuration options on this
> page. Similarly the tooltips for the new options for ID Token support will
> contain the tooltip, that you should configure JWKS URL or "hardcode"
> encryption key in the tab "Keys" .
> The bonus point will be the possibility to view the keys downloaded from
> JWKS URL and the ability to invalidate the keys of the individual client
> from the cache (currently it's possible to invalidate just globally for the
> whole realm AFAIK).
> TBH I am not sure whether to add admin console support in this PR or have
> the follow-up PR.
> keycloak-dev mailing list
> keycloak-dev mailing list