[keycloak-dev] offline access tokens part 2

[Bill Burke]

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.

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