[keycloak-dev] offline access tokens part 2

[Bill Burke]

On Tue, Mar 27, 2018 at 2:55 PM, Marek Posolda <mposolda at redhat.com> wrote:
> Dne 27.3.2018 v 16:14 Bill Burke napsal(a):
>
>> On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>>
>>> Dne 27.3.2018 v 04:41 Bill Burke napsal(a):
>>>>
>>>> These are my thoughts for implementing offline access tokens:
>>>>
>>>> * offline access tokens MUST be validated.  This means that if they
>>>> are used during bearer token requests, the service must validate the
>>>> token with the token endpoint.
>>>> * These tokens MUST be rejected by older keycloak clients as our
>>>> adapters dont' have support for them.
>>>> * offline access tokens will not be stored in the database.  Instead
>>>> they will be JWEs or JWS that link to an offline user session. (our
>>>> current offline access implementation).  They will be revokable just
>>>> like any other offline session and in the same manner.  This makes the
>>>> implementation simple.
>>>>
>>>> * There will be 4 modes for configuring clients
>>>> - client automatically receives offline access tokens (maybe not
>>>> include a refresh token in this case)
>>>> - client may request an offline access token
>>>> - client requires consent before providing an offline access token
>>>> - client is not allowed to ask for offline access tokens (default)
>>>>
>>>> Any other thoughts on this?
>>>
>>> How will client tells that it wants this offline token? Will it be some
>>> special value of scope parameter like "scope=persistent_token" ?
>>>
>> Yeah, I think so.
>>
>>> I can imagine that issuing this token will be handled by protocol mapper?
>>> Some protocolMapper implementation, which will change token expiration to
>>> 0
>>> (which means infinity) and change token type to something like
>>> "persistent"
>>> ?
>>>
>>> Once we have clientScopes in, it will be easily possible to ensure that
>>> this
>>> protocolMapper is used just if "persistent_token" scope is used as
>>> protocolMapper will be just configured on "persistent_token" client
>>> scope.
>>> However the clientScopes PR will likely need to wait for few weeks or
>>> so...
>>>
>> I don't think it should be implemented as a protocol mapper, or as a
>> regular access token.  #1 you'll still need to recognize that the
>> client is requesting an offline access token because you'll need to
>> create an offline user session.  #2, We want the offline access token
>> to be as small as possible and for it to contain no information an
>> attacker could use.  I would implement it as a JWE that contained a
>> user session id and the scopes the client has been consented for.  #3
>> You don't want to implement it as an access token as you want older
>> Keycloak clients to reject them in bearer token requests.   Where
>> protocol mappers would come in is when the client validates the token.
>> In that case an unmarshalled id token or access token would be created
>> with using the client scopes the token was minted for.
>
> Ok
>
> BTV. I've already did some JWE stuff and it's currently used for OAuth code.
> It's in "core" module and it's already in Keycloak master.
>
> We discusssed with Pedro and Sebastian Schuster from community in the other
> thread, that it will be good to add "scope" as the builtin claim into our
> access token itself. That way, the refresh tokens and offline tokens (and I
> believe new persistent token too) will also contain "scope", as they inherit
> from AccessToken class. JIRA with some more context is
> https://issues.jboss.org/browse/KEYCLOAK-6883 . This is not yet done in my
> clientScope PR, but I think it will be quite easy addition.

Yes this is good.  Scopes allowed should be in the auth session too.
I think I have done that in my Openshift branch as I have to validate
requested scopes vs. allowed openshift scopes when validating a token.

>>
>>
>> Question, when you create a client, and specify what scopes its
>> constructed of, can you mark one or more "inherited" scopes as
>> requiring consent?  Might be a great way to re-use scopes for clients
>> that require consent.
>
> Yes. If I understand correctly, this shouldn't be a problem.
>
> ClientScope has on/off flag "Display On Consent Screen" . The client still
> has "Consent Required" flag. In case that client is marked as "Consent
> required", then consent screen will show all the clientScopes marked with
> "Display On Consent Screen". By default, all clientScopes has "Display On
> Consent Screen" switched to ON.
>
> Note that when client itself doesn't have "Consent Required", the consent
> screen is never displayed. Same behaviour like in current master.

Might be nice to not require "consent required" on the scope itself,
but when you attach it to the client.

i.e. Client Foo has scopes A, B by default which don't require
consent, but it can also request scope C if the client asks for it and
consent is granted.
Client Bar has scope C by default and doesn't require consent.  Maybe
that's something that can be supported later.


-- 
Bill Burke
Red Hat