[keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing

[Marek Posolda]

+1

Having the configuration in adapter (keycloak.json) won't scale also 
because REST services (bearer-only clients) will need to verify 
signatures by "frontend" clients, but each frontend client can use 
different algorithm to sign it's token. So keycloak.json of bearer-only 
clients would need to have some configuration map to track all of 
this... Also "rotation" of algorithms will be impossible (if 
administrator changes the algorithm for client in admin console, the 
adapter configuration in keycloak.json will need to be updated and hence 
application restarted...)

But I think we don't need to add any new endpoint, but just re-use 
existing client registration endpoints for that? OIDC Client 
registration has various metadata for clients like 
id_token_signed_response_alg, id_token_encrypted_response_alg, 
userinfo_signed_response_alg etc. See [1]. Also we have support for 
Dynamic client registration management [2], so client applications are 
able to "download" the client's metadata from the endpoint.

The specification enforces that requests are authenticated by Client 
Registration Access Token. But ATM we also support authentication by 
bearer tokens, which is great. When application sees the bearer token 
signed/encrypted by unknown algorithm, it can send the request to KC 
registration/management endpoint of particular client to download the 
client's metadata. This will work fine also for bearer-only clients. The 
bearer-only client can parse the token and send the request to the 
registration/management endpoint of particular "frontend" client the 
token was issued for to determine the right algorithms etc.

[1] 
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
[2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05

Marek

On 26/06/18 18:25, Stian Thorgersen wrote:
> I don't really like the idea of having to reconfigure to make the 
> adapter accept new signature. I know oidc well known  endpoint doesn't 
> have signature algorithm for access token, but we could add one and 
> have adapters pull from the server what algorithms to accept.
>
> On Tue, 26 Jun 2018, 11:00 Marek Posolda, <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 30/05/18 09:35, Stian Thorgersen wrote:
>>>     I think it might be better to determine which kind of Token Signature
>>>     Provider be used by not parsing JWS, for example, looking up Client or
>>>     Realm settings.
>>>     This PR might have impacts on keycloak's performance because it has parsed
>>>     JWS to determine it every time keycloak receives JWS Token.
>>>
>>     On the server-side that is easy. On the adapter side that would probably
>>     require adding a property to keycloak.json to set the algorithm. In either
>>     case it should probably default to RSA for existing realms at least, but we
>>     could consider setting it to ES256 for new realms.
>>
>     +1
>
>     Parsing token signature to determine algorithm should be avoided
>     IMO. AFAIR Some OAuth/OIDC vendors had security issues in the
>     past, that they parsed the header with "none" algorithm and then
>     client applications automatically trust unsigned tokens. We should
>     make sure this is not possible.
>
>     Marek
>