Accepting Offline Token in Server Application

Getting advice
1

I have a customer driven use case for long lived tokens. Unfortunately some customers will not accept a solution that includes periodic token refreshing.

Here are the stated requirements

  • User must be able to acquire a long lived token through a client either using a service user (client credentials grant) or regular user (direct access grant). This token must be acceptable by my server side application for a long time period (lets say 1 year).
  • User must be able to revoke a long lived token at any time.

My options seem to be the following

Set Client Level Token Expiration

  1. Set client level token expiration (and max sso session) to 1 year
  2. Make user call the token revocation endpoint to revoke tokens
  3. Implement a listener in my server side application that listens for token revocation events and populates an in memory block list using the token identifiers (jti claim) which is used to fail authentication during request processing

Offline Tokens

  1. Allow user to acquire an offline_access token
  2. Accept the token in requests to my server side application.
  3. During request processing in the server side application, check if the token type is offline.
    • If so use token to acquire an access token.
      • Fail request if token acquisition fails (due to offline token expiration or revocation)
      • Otherwise perform request with the access token
    • If not and the type is “bearer” perform normal request processing.

Build an extension

  1. Build an extension to the token grant workflow that accepts a custom long_lived scope. This scope will generate a token with a 1 year expiration (overriding realm and client expiration configuration) and will store a record of the token in keycloak which will also provide a revocation UI. We can cap the number of these tokens to something manageable (say 50 per client).

There are pros and cons to these approaches. The offline token approach gets me closer to the functionality that the customer requires with minimal effort, it also has the added benefit that the token will be kept up to date whereas long lived tokens could contain stale information like role mappings. However it is a highly unorthodox use of refresh/offline tokens.

Can I get some guidance here, also are there other approaches that I haven’t considered?