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.
On 27 March 2018 at 04:41, Bill Burke <bburke(a)redhat.com> wrote:
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