I see. I think you guys have very good points. I've created JIRA
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]
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@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%0AG...
|
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(a)bosch-si.com
<mailto:Sebastian.Schuster@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@redhat.com
<mailto:psilva@redhat.com>]
*Sent:* Montag, 19. März 2018 13:19
*To:* Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
*Cc:* Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>; keycloak-dev
<keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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
<
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(a)redhat.com <mailto:mposolda@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(a)redhat.com <mailto:mposolda@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(a)redhat.com <mailto:mposolda@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(a)redhat.com
<mailto:mposolda@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&...
|
www.bosch-si.com
<
http://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(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>