[keycloak-dev] Client Scope naming

Mon Mar 19 15:08:16 EDT 2018

+1

On Mon, Mar 19, 2018 at 2:31 PM, Marek Posolda <mposolda at redhat.com> wrote:

> 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> 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
>> Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100
>> <+49%2030%20726112100> | 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]
>> *Sent:* Montag, 19. März 2018 13:19
>> *To:* Marek Posolda <mposolda at redhat.com>
>> *Cc:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev <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>
>> 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>
>> 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>
>> 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>
>> 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>
>> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30
>> 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bo
>> sch-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
>> > 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>