Token duration per scope

Overview


This document explains access/refresh token duration per scope. 


Introduction


In Authlete 1.1, access (refresh) token duration can only be set for each service. Since Authlete 2.0, it can be set for each scope. This allows more granular token duration settings such as "making token duration shorten when the write scope is requested, since tokens issued with the write scope are considered to have a higher level permission than others". 

How to determine token duration


Since Authlete 2.0, token duration is determined as follows. (NOTE: since Authlete 2.1, it is determined in another way. See "Token duration per client (TBW)" for more detials.)

(Suppose that duration is the resulting token duration.)

1. Get the value of the token duration of the service and set duration to it as its initial value.
2. If token duration is set for any of the requested scopes, perform the following steps.
  2.1. Get the minimum value out of all the token durations that are set for those scopes.
  2.2. Compare the current value of duration and the value obtained in 2.1. and then, set duration to the smaller one.

Configurations


To use this feature, you need to set scope attributes on service owner console. For more details, see "Scope attribute".

Example


In the following examples, we issue access tokens by simulating the implicit flow under several conditions. Note that we have a service with the following configurations:

  • Token duration for the service is 86400 seconds.
  • The service has read and write scopes and token durations for them are as follows:
    • Token duration for read scope is 3600  seconds.
    • Token duration for write scope is 600 seconds.

1. When no scope is requested

{
  "type":"authorizationIssueResponse",
  "accessTokenDuration":86400,
  "responseContent":"http://localhost:4180/api/mock/redirection/5191537045#access_token=xbNhif-bsWOPyRasrEFUFurBSQUHnarjv6sMz8cSDjg&token_type=Bearer&expires_in=86400&scope=",
  ...
}

=> The access token duration for the service is used.

2. When the read scope is requested

{ 
  "type":"authorizationIssueResponse",
  "accessTokenDuration":3600,
  "responseContent":"http://localhost:4180/api/mock/redirection/5191537045#access_token=8ihMgxhMf-HYBy-O2rYVlMHEQD7WcvFGUhaXfP3YZHs&token_type=Bearer&expires_in=3600&scope=read",
  ...
}

=> The access token duration for the read scope is used.

3. When the read scope is requested

{ 
  "type":"authorizationIssueResponse",
  "accessTokenDuration":600,
  "responseContent":"http://localhost:4180/api/mock/redirection/5191537045#access_token=lZ4rjCLlwDvgO2wgOaXhDhNGMhpUE_yGi3pyTPcHFyU&token_type=Bearer&expires_in=600&scope=write",
  ...
}

=> The access token duration for the write scope is used.

4. When the read and write scopes are requested

{
  "type":"authorizationIssueResponse",
  "accessTokenDuration":600,
  "responseContent":"http://localhost:4180/api/mock/redirection/5191537045#access_token=3zQNzTiX5MUxO1Gy0ZFfD7mhn3U1Cg3Q15rhjNob6uc&token_type=Bearer&expires_in=600&scope=read+write",
  ...
}

=> The access token duration for the write scope is used.
How did we do with this article?