[keycloak-dev] Configurable signature algorithms

[Hynek Mlnarik]

+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 at 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 at 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 at 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 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
> >>
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>