2:18 a.m.
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(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 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%2...
[2]
https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2...
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2...