[keycloak-dev] Configurable signature algorithms

Marek Posolda mposolda at redhat.com
Wed Aug 22 03:17:32 EDT 2018


Not sure how likely is that. Maybe we can have just one option and 
introduce the other once there is use-case for that?

The OIDC specification has a way to use separate signature/encryption 
algorithms for ID tokens, UserInfo response and "request" object - 
http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata 
. So it's possible that at least for those we may need an ability to add 
separate algorithms to conform the specs?

Marek

On 22/08/18 08:45, Stian Thorgersen wrote:
> The use-case for separate is if the front-end app that is using id token
> uses one algorithm, while back-ends who are using the access token expects
> a different algorithm. Now, the question is how likely is that.
>
> On Wed, 22 Aug 2018, 03:55 Sebastian Laskawiec, <slaskawi at redhat.com> wrote:
>
>> Setting them separately seems more flexible to me. On the other hand, it
>> is hard for me to imagine a use case where a client would use two different
>> signature algorithms...
>>
>> +1 for having two separate options. We can always set them equal in the
>> Admin Console if we wish.
>>
>> On Wed, Aug 22, 2018 at 2:12 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Currently, Keycloak always use RS256 both for access tokens and id tokens.
>>> We're working on introducing support for more algorithms and the ability
>>> to
>>> change the default for a realm and also for a client.
>>>
>>> Now the question is should have we two options one for access token and
>>> another for ID token. Or just one for both?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




More information about the keycloak-dev mailing list