Skip navigation
All People > Sascha Preibisch > Sascha Preibisch's Blog > 2016 > January

I often get the question on how to create token lifetimes per client. OTK by default issues token with a global lifetime which becomes a limitation in many cases. This blog post is about customizing token lifetimes per client.


Since OTK-3.3.01 (January 2016) client_id's can be configured with a JSON structured custom field. The content of that field is available in policy for certain tasks during OAuth request processing. Here are the required steps from "Register a new client" to "issue token with custom token lifetime":


The process is divided into 2 parts and will take about 15 minutes to implement:

  1. Register a test client in OAuth Manager
  2. Modify one policy


It starts with OAuth Manager (https://your-gateway:port/oauth/manager):

  1. Select "Clients -> Register A New Client"
  2. Use the name "AAA Test Client", the Organization "AAA Test" and click "Register"
  3. Select "Clients" and look for "AAA Test Client"
  4. Select "List Keys -> Edit". At the bottom of the screen you will find a custom field containing "{}" (an empty JSON structure)
  5. Paste this content into the custom field:  {"lifetimes": {"oauth2_access_token_lifetime_sec": 86400, "oauth2_refresh_token_lifetime_sec": 432000}}
  6. Click "Save"


This client_id now has a custom field which we will use to generate access_token with a lifetime of 86400s (1 day) and refresh_token with a lifetime of 432000s (5 days).


The next step is to modify the policy that generates token: OTK Generate OAuth Token. This will be done in the Policy Manager:

  1. Login to Policy Manager using admin credentials
  2. In the lower left window search for "OTK Generate OAuth Token" and open the policy in the editor window; turn on "Show Comments" and "Show Assertion Numbers"
  3. On line 5 you will find "OTK Token Lifetime Configuration". That assertion generates global lifetimes which we will overwrite
  4. All together, including container assertions (At least one ..., All assertions ...) we have to add 9 lines of policy


To give you an idea, the result of this customization will look like shown below. I hope you can see that it is easy to do:


Ok, let's get started:

  1. line 6: add the assertion "At least one ..."
  2. line 7: add the assertion "All assertions ..." as the fist child of the "At least one ..." assertion
  3. line 8: add the assertion "Continue Processing" as the second child


You should have this picture now (without the comments in the screenshot unless you also added those):


All the next assertions will be added into the block on line 7. I will explain each line with all necessary details:

  1. line 8: add the assertion "Set Context Variable". Configure it as follows:
    1. Variable Name: custom_json
    2. Data Type: Message
    3. Content-Type: application/json; charset=UTF-8
    4. Expression: ${custom}. The variable ${custom} contains what was specified in the custom field in OAuth Manager
  2. line 9: add the assertion "Compare Expression" to check if the content includes the value "lifetimes" which indicates that custom lifetimes were configured
    1. Variable: ${custom_json.mainpart}
    2. Add ... Simple Comparison ...
    3. Select "contain" in the second drop-down list, select "does" in the first drop-down list
    4. Right Expression: lifetimes
    5. Uncheck "Case Sensitive", click "OK"
    6. Click "OK" to close the assertions dialog
  3. line 10, 11: add the assertion "Evaluate JSON Path Expression". Both are similar, one is extracting the "access_token" lifetime, the other the "refresh_token" lifetime:
    1. for the access_token lifetime:
      1. Expression: $..lifetimes.oauth2_access_token_lifetime_sec
      2. Other Message Variable: custom_json
      3. Variable Prefix: at_lifetime
    2. for the refresh_token lifetime:
      1. Expression: $..lifetimes.oauth2_refresh_token_lifetime_sec
      2. Other Message Variable: custom_json
      3. Variable Prefix: rt_lifetime
  4. line 11, 12: add the assertion "Set Context Variable" to overwrite the global lifetime variables oauth2_access_token_lifetime_sec and oauth2_refresh_token_lifetime_sec
    1. for the access_token lifetime:
      1. Variable Name: oauth2_access_token_lifetime_sec
      2. Data Type: String
      3. Expression: ${at_lifetime.result}
    2. for the refresh_token lifetime:
      1. Variable Name: oauth2_refresh_token_lifetime_sec
      2. Data Type: String
      3. Expression: ${rt_lifetime.result}


Click "Save and Activate", create a revision history comment "Customized Token Lifetime".


That's it!


You can now use a tool like Chrome's Advanced Rest Client and use the "password" grant_type with your new client_id and client_secret. The response will have the configured access_token lifetime of 86400 s in the response:



"access_token": "065d8941.....ae29b9e1e1"

"token_type": "Bearer"

"expires_in": 86400

"refresh_token": "f03f133f.....42841e0722"

"scope": "oob"



Any feedback is welcome, especially if it helps you!

Last week we have released a new OAuth Toolkit, version 3.3.01. The version mainly contains bug fixes but also a nice new feature:

  • a custom field for client_id's
  • a custom field for issued access_token


Why is this a nice feature? Because those fields enable users of OTK to implement more validations on OAuth protected APIs and customized behaviour for certain client's.


I will write a few blog posts about ideas on how to use those fields.

Sascha Preibisch

Latest news in OAuth

Posted by Sascha Preibisch Employee Jan 13, 2016

I have been quiet for a while. But recently new OAuth related RFC drafts came up. I just want to share that info with anyone interested.


Please follow these links to see the latest works that are related to threats referred to as “IdP Mix-Up” and “Malicious Endpoint”:

- Mike Jones: self-issued » OAuth 2.0 Mix-Up Mitigation