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? Maybe this should be implemented in conjunction with a reference token feature too? -- Bill Burke Red Hat _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda <mposolda(a)redhat.com&gt; 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.

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.

So I think it woudl work like this. I'm making guesses to how Client Scopes was implemented as I don't fully remember your presentation: * We create a built in "persistent-token" scope. This is empty. No protocol mappers, no nothing. * persistent access tokens are JWEs that contain a user session id and scopes client is allowed to access. * When a client is created in the admin console, the "persistent-token" scope is added as a default scope. In this case, this means that the client should automatically get a persistent token. * If the client requires consent, then mark the "persistent-token" scope as requiring consent for that client * persistent tokens are created as a JWE that contains a user session id and scopes the client is allowed to access * When a persistent token is minted, it does the same offline user session logic that "offline access" does. * persisten tokens must be validated with the Keycloak token userinfo or token introspection endpoints depending on the level of information needed.

BTW, how long is a "few weeks"? I won't be able to release openshift/kubernetes integration until I can add "allowed groups" to client scopes. Access decisions are entirely group-membership based. If you're interested in more detail, read further:

When Openshift and kubernetes validate a token they call a validation endpoint that returns a username and group membership for that user. Never roles. Kub/OS have roles, very specific roles, but access decisions are based on user-role and group-role bindings. What's even more interesting is that users and groups are just strings to Kub/OS. You don't create a user or group, you just specify the username or group string when you create a role binding. The kubernetes integration is actually ridiculously easy and took me like 2 hours. It required just implementing a special validation endpoint for keycloak tokens. Bill

On Tue, Mar 27, 2018 at 2:55 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > Dne 27.3.2018 v 16:14 Bill Burke napsal(a): > >> On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda <mposolda(a)redhat.com&gt; >> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > 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. > FYI, didn't ignore you. I replied to Marek's email first, got distracted before I could read and reply to yours. I think this is a reference token vs. non-reference token debate. Let's first talk about offline access tokens. In thinking further on your suggestion, what about instead of per client expiration, shouldn't we instead have an "offline access token timeout"? Access tokens created for offline access should have this timeout, maybe default to "offline idle" timeout? One thing we have to be sure of is that these offline access tokens are valid across server restarts.

In retrospect, I mixed up offline access and the idea of a reference token. I think whether an access token is a reference token or not is orthogonal to whether it is offline or not. Reference tokens must always be validated. Non-reference tokens can be used as bearer tokens without validation. I think we should have a global switch on what the access token type should be by default, then allow clients to override. You should also be able to separately configure whether a reference token should be used or not for offline and non-offline access. In the future we might even want to offer one-time reference tokens that can only be validated once. FYI: all tokens in Kubernetes and Openshift are reference tokens (and offline).

Reference tokens require validation and shouldn't be excepted ever for bearer token requests unless validated. Using expiration time to determine the token type is not a good solution. Other than just being a hack, you remove the ability to have any expiration on the token. I really prefer that reference tokens be completely opaque to the client. A JWE IMO.

-- Bill Burke Red Hat