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

[Stian Thorgersen]

On Thu, 28 Jun 2018, 16:13 Marek Posolda, <mposolda at redhat.com> wrote:

> On 28/06/18 10:12, Stian Thorgersen wrote:
>
>
>
> On Wed, 27 Jun 2018 at 09:31, Marek Posolda <mposolda at redhat.com> wrote:
>
>> +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.
>>
>
> I wasn't thinking adding a new endpoint. We should use OIDC well-known
> endpoint. However, that doesn't include any attributes for the access
> token, only ID token. Which is of course due to the fact that the access
> token is opaque in OIDC. We could for instance add
> "access_token_signed_response_alg".
>
> Clients would by default check the OIDC well-known endpoint for what
> algorithm to use, but it should also be possible to override in
> keycloak.json as that OIDC well-known would say the realm default, but we
> want to be able to override the algorithm for individual clients.
>
> IMO OIDC well-known endpoint is not good for that. It's not the endpoint
> to be useful for retrieve metadata of specific client, rather it's global
> for a realm. Even for ID token, there is not single signature algorithm.
> There is just list of supported algorithms in
> id_token_signing_alg_values_supported .
>
> I wonder that for our adapters, we can just use the Client Registration
> (Management) endpoint of our own representation - the endpoint of
> DefaultClientRegistrationProvider.getDefault() . That's our own rep, so we
> are fine to return the accessToken signature algorithm. We can ensure that
> algorithm is always returned (We will return client specific algorithm or
> fallback to realm default algorithm if client doesn't have one set). We can
> invoke that endpoint with the bearer-token, which adapter will always have
> - it can just use the token it wants to verify signature for. Any reason
> why it won't work?
>
> I wouldn't add anything to keycloak.json. IMO it would suck because:
> - If algorithm is changed by admin in KC admin console, adapter will need
> to be re-configured in keycloak.json and restarted (no automatic algorithm
> "rotation" support)
> - Configuration of algorithm will be duplicated on both adapter and server
> - Bearer-only clients can be invoked with tokens of various "frontend"
> clients signed by various different algorithms. So the configuration in
> keycloak.json would be quite complicated here.
>

The way I see it is the realm should have its supported algorithms
advertised in the well-known endpoint. It should also have a default set,
but  that doesn't  need to be advertised. Clients should check that tokens
are signed with an algorithm from that list. Now if a client wants tokens
issued to it with a different algorithm than the realm default it should
have the option to set a different algorithm for itself. I do not think
there's any need to update this automatically and I think setting it in
keycloak.json is fine. If we want it updated automatically we should do it
by adding support for clients to do dynamic client registration as well as
be able to get updates either pushed or pulled. For bearer clients they
should have an option to limit the set of algorithms they support and again
Keycloak.json is fine here. I believe all clients secured with Keycloak
adapters would just use the the realm default anyways. Having the option to
override for clients is more aimed at non-Keycloak adapters which may for
instance not support es256, but only rs256, while the user would like to
use es256 whenever possible.


> Marek
>
>
>> 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.
>>
>
> Same as well-known. Dynamic client registration metadata from OIDC doesn't
> specify anything for access token sign algorithm. So we would have to add
> our own.
>
>
>>
>> [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> 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
>>>
>>
>>
>>
>