[keycloak-dev] Client Scope naming

Wed Apr 4 05:07:50 EDT 2018

Great discussion, I think many folks are looking forward to enhanced scope
support in Keycloak.

I also think that having scopes in the RefreshToken as well as the
AccessToken
structure is useful.

Some additional remarks:
* backwards compatibility
Changing the representation of the token structures might cause problems
for clients using an older version of a Keycloak adapter when trying to
unmarshall
the JSON due to the unknown "client-scopes" field.
This incompatibility should be mentioned in the migration guides for 4.x.

* Scopes in general
As far as the current discussion goes the current understanding of custom
scopes (apart from role based scopes) seems to be "scoped" to client-level
since there is no mentioning of something like global scopes on realm level.
I wonder whether it would make sense to have support for broader global
scopes
on realm level, this could help to implement cross-cutting scopes across
all clients.

* Scope translation / rendering on consent page
When requesting consent for a scope from the user in a consent screen it
would be handy to have a way to use parameters for the translation of a
particular scope.
This would allow to render consent requests like
"Access to email: foo at bar.com" , "Access to User attribute: Date of Birth"

Cheers,
Thomas

2018-03-20 10:56 GMT+01:00 Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com>:

> +1
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 19. März 2018 18:31
> To: Pedro Igor Silva <psilva at redhat.com>; Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Client Scope naming
>
> I see. I think you guys have very good points. I've created JIRA
> https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return
> "scope" in the access token.
>
> With my PR, the "scope" is already returned in the TokenResponse as
> defined in the OAuth2 [1] . But Introspection endpoint doesn't return
> "scope" because access token doesn't yet have scope in my PR.
>
> I've just added scope information to the refresh token, but I didn't add
> scope claim directly. I've added "client-scopes" claim to the refresh token
> with the list of UUIDs referencing used client scopes. I did this just
> because:
> a) refreshToken is opaque to the application and just Keycloak needs to be
> able to read it and decode used client scopes from it.
> b) referencing by UUID is in theory bit safer instead of referencing by
> scope names. I was just thinking about corner case when admin deletes scope
> "foo" and then re-create scope "foo" again, it would be something different
> then what user granted, even if it's same name. Hence I used reference by
> UUID. But this is probably just corner case, which won't happen in practice.
>
> When thinking more about it, it seems that none of the points (a) and (b)
> justifies this unecessary complication with using "client-scopes" rather
> then just "scope". It will be just easier if both access token and
> refreshToken contains "scope" claim in the OAuth2 format. WDYT?
>
> [1] https://tools.ietf.org/html/rfc6749#section-5.1
>
> Marek
>
> On 19/03/18 13:59, Pedro Igor Silva wrote:
>
>
> On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>
> wrote:
> If you support scopes you definitely need some claims in the token that
> represent the granted scopes. Otherwise as a resource server you could only
> do token introspection to retrieve the scopes and having to do this always
> defeats the purpose of self-contained tokens. The fact that Keycloak
> supports defining custom mappings of scopes to roles (and now arbitrary
> claims with token mappers) is just fine, I think.
>
> Btw. access tokens and scopes is not always user consent, see client
> credentials grant…
>
> Yeah, that is why I said usually. My initial idea was discuss cases where
> scopes are *not* limited to the protected resources under the control of
> the client.
>
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | <
> https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+
> Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g> GERMANY | www.bosch-si.com
> <http://www.bosch-si.com>
> Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
> 726112-100<tel:+49%2030%20726112100> | Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
> Stefan Ferber, Michael Hahn
>
>
> From: Pedro Igor Silva [mailto:psilva at redhat.com<mailto:psilva at redhat.com
> >]
> Sent: Montag, 19. März 2018 13:19
> To: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
> Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>>; keycloak-dev <
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
> Subject: Re: [keycloak-dev] Client Scope naming
>
> OAuth2 does not define any format for access tokens - as you know they are
> opaque - so you can push whatever you want into it, use it as a reference,
> etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that
> token introspection response includes a "scope" claim.
>
> The main point I'm trying to make here is that access tokens usually
> represent user consent. Consent is not the same thing as a role granted to
> an user. So I may want to build my REST API without any role mapping but
> based on user consent to specific scopes. Where these scopes grant access
> to different parts of my API.
>
> But I think that should also be possible with your changes. We would just
> need to have a mapper that adds to an access token the scopes granted by
> the user to a client. Or maybe make this information also available via
> introspection endpoint (which I think we are missing).
>
> On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> Yes, and this (almost) all should be possible now with new client scopes
> stuff I did. It won't be a problem to have "device.localization" client
> scope, which doesn't have any roles or protocolMappers. And require this
> client scope to be present on consent screen.
>
> Only thing, which is not directly available OOTB from what you mentioned,
> is the: Check if scope "device.localization" is granted by introspecting
> the token. For instance, checking a scope claim within a token.
>
> For now, I've just added client scopes to refresh token, but that one is
> opaque to the adapter. I did not add anything to access token or ID token.
> The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in
> our tokens. Do you know if it's defined in some other specification? We can
> do our extension and add some stuff into access token similarly like we did
> for roles, but not sure we want that?
>
> Marek
>
>
> On 16/03/18 14:27, Pedro Igor Silva wrote:
> We already had discussions a long time ago about it. I do think that
> scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
> are too role-based ...
>
> Thinking it simple, as an admin user I may want to:
>
> * Create a scope "device.localization" with consent required for a client
>
> As a client:
>
> * Ask for "device.localization" scope when obtaining tokens from AS
>
> As a resource server:
>
> * Check if scope "device.localization" is granted by introspecting the
> token. For instance, checking a scope claim within a token.
>
> See, no role mapping, no scope -> role mapping, etc. User just consented
> to grant "device.localization" scope.
>
> On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> On 16/03/18 13:24, Pedro Igor Silva wrote:
> That is what I was thinking. In authz services, scopes are not related
> with roles or protocol mappers. They are just a string representing
> something you can perform/access in a protected resource. Use client scopes
> to represent such concept and remove "authz scopes" tab is a bit overkill,
> I think.
>
> Currently, if I have a Localization API and a scope that grants access
> based on a "device.localization"  scope, I would need to create a
> role/mapper and associate it with a client scope, right ?
> You mean that you have support for "device.localization" value of OAuth
> scope parameter? Yes, you would need to create clientScope and associate
> role "device.localization" with it. With client scopes support, the scope
> parameter doesn't reference single role, but single client scope.
>
> Marek
>
>
> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> Scope parameter would reference client scopes. For example scope parameter
> "openid email profile offline_access" will reference client scopes "email",
> "profile" and "offline_access" (openid is jsut generic OpenID Connect
> marker).  And each client scope is set of protocolMappers and/or Role scope
> mappings.
>
> Marek
>
>
> On 15/03/18 12:39, Pedro Igor Silva wrote:
> How a scope looks like now after your changes ? Are they just strings
> referencing a set of one or more roles ? Or they are still roles ?
>
> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> That's good question. As you know, we also have "Scope" tab (used to
> specify scope role mappings of client) and "Authorization scope", which
> is used when Authorization is enabled :)
>
> Marek
>
> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> > Hi,
> >
> > I saw there are activities to replace client templates with client
> scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
> client wants to do with the granted access (e.g. this could be used to
> determine the purpose of processing some data for GDPR compliance). Since
> Keycloak will also support UMA 2.0, I am a little concerned this might lead
> to some confusion. As you know, there are only two hard problems in
> computer science: cache invalidation, naming things, and off-by-one errors.
> ☺ WDYT?
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Dr.-Ing. Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+
> 12109+Berlin+%7C+GERMANY&entry=gmail&source=g> | www.bosch-si.com<
> http://www.bosch-si.com><http://www.bosch-si.com>
> > Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
> 726112-100<tel:%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian
> .Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr. Stefan Ferber, Michael Hahn
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto: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
>