+1
We could do it similarly for SAML clients (default set in realm, client can
override if required) to have consistent experience. Indeed the set of
algorithms would be different.
On Wed, Aug 22, 2018 at 11:55 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
What I'm thinking now is to have a default singing algorithm for
the realm,
but for a client have the option to specify ID token, user info and access
token algorithms separately. Most clients won't have to touch those
settings at all and can just rely on the realm default. I don't think
there's a need to have separate for a realm.
On Wed, 22 Aug 2018 at 09:23, Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
> Per this explanation
> <
https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/>
> the id_token is meant for the specific client only (is signed with a
> secret that is
> known to that client). On the other hand (from that article), the API /
> access_token can be of any type
> (not necessarily a JWT based one), and it is expected to have audience
set
> to API's unique identifier.
>
> To me this sounds, like certain clients might want to choose just some
> specific algorithm to share
> the secret known to them with the frontend. Something like choosing
> specific protocol version
> (TLS v1.0, TLS v1.1, TLS v1.2 etc.) in the case of SSL/TLS connections.
It
> might be possible some
> clients wouldn't support all signature algorithms supported / implemented
> by Keycloak server. So having
> id_token / access_token signature algorithms configurable, would allow
> them to choose the one, they
> are able to communicate under. I agree that in majority of the cases, the
> algorithms in both cases would
> be the same. But having the option to specify different algorithms for id
> and access tokens, looks to me
> more clients might be able to connect / use the services, compared with
> the case when just one identical
> algorithm would be enforced / used for both type of tokens.
>
>
> On Wed, Aug 22, 2018 at 8:45 AM, Stian Thorgersen <sthorger(a)redhat.com>
> 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(a)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(a)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(a)lists.jboss.org
>> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev