[keycloak-dev] Encrypted OIDC ID Tokens support and admin console

Wed Jun 5 09:27:09 EDT 2019

Thanks everyone for the feedback. Created 
https://issues.jboss.org/browse/KEYCLOAK-10462 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 SAML 
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.

Marek

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 keys?
>
> +1 to separate pr as well
>
> On Wed, 5 Jun 2019, 09:21 乗松隆志 / NORIMATSU，TAKASHI, 
> <takashi.norimatsu.ws at hitachi.com 
> <mailto:takashi.norimatsu.ws at hitachi.com>> wrote:
>
>     Hello,
>
>     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 at lists.jboss.org
>     <mailto:keycloak-dev-bounces at lists.jboss.org>
>     <keycloak-dev-bounces at lists.jboss.org
>     <mailto:keycloak-dev-bounces at lists.jboss.org>> On Behalf Of Marek
>     Posolda
>     Sent: Friday, May 31, 2019 4:31 PM
>     To: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and
>     admin console
>
>     We have PR for introducing encryption support for OIDC ID Tokens.
>     See [1] and [2].
>
>     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" the 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 "Keys" . That will allow to have switch "Use
>     JWKS URL" and then configure JWKS URL (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 "Credentials ->
>     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.
>
>     WDYT?
>
>     [1]
>     https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768
>     [2]
>     https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779
>
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>