[keycloak-dev] offline access tokens part 2

Wed Mar 28 00:58:04 EDT 2018

Since my reply was ignored I'm going to repeat myself.

I would rather have the option to override the expiration of access tokens
expiration on a per-client basis. We could allow clients to use the global
expiration, a client specific expiration or no expiration at all. When a
JWT has no expiration set the client should always use the token
introspection endpoint to validate the tokens.

Perhaps also combine that with client scopes to make it possible for a
client to request one token with longer expiration for a specific use-case.
For instance if a client needs to invoke some background process that takes
longer than the regular access token.

I think that approach will be simpler to implement and also cover more
use-cases.

I don't see the need to have a different scope than what we have today.
This should be a config option on the client for the current offline scope.
There's no need to introduce a new non-common scope for this stuff.

On 27 March 2018 at 21:36, Bill Burke <bburke at redhat.com> wrote:

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