Updating token lifetime
Updating token lifetime in the mapping rule
Scenarios exist where based on an incoming scope, the lifetime of the generated token needs to be modified. A new mapping rule utility is introduced to address these scenarios.
Mapping rule snippet
importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.OAuthMappingExtUtils);
IDMappingExtUtils.traceString("Entering pre token mapping rule")
IDMappingExtUtils.traceString("Principal name is " + stsuu.getPrincipalName());
IDMappingExtUtils.traceString("STSUU: " + stsuu.toString());
var grant_type = stsuu.getContextAttributes().getAttributeValueByName("grant_type");
var scope_test_param = stsuu.getContextAttributes().getAttributeValueByName("scope");
IDMappingExtUtils.traceString("test_param: " + scope_test_param);
if(scope_test_param != null && scope_test_param == "profile"){
cfgOverride["at_lifetime_in_secs"] = 2000;
cfgOverride["rt_lifetime_in_secs"] = 4000;
}
else if(scope_test_param != null && scope_test_param == "email" && grant_type == "refresh_token"){
cfgOverride["at_lifetime_in_secs"] = 1000;
cfgOverride["rt_lifetime_in_secs"] = 3000;
}
- cfgOverride is a JSON object, that provides the ability to override, access token and refresh token lifetime.
- cfgOverride is available only at the pre token mapping rule.
- at_lifetime_in_secs represents access token lifetime in seconds.
- rt_lifetime_in_secs represents refresh token lifetime in seconds.
- at_lifetime_in_secs indicates how long the access token is valid.
- rt_lifetime_in_secs indicates how long the refresh token is valid.
Note
Refresh token lifetime indicates the grant lifetime, if a refresh token lifetime is set to a value lesser than the access token, when the refresh token expires the entire grant will expire, so the access token belonging to that token will also expire.
Refresh Token lifetime and fault tolerance
The token lifetime can be configured in multiple ways; however, it is determined according to a defined order of precedence.
- If there is a mapping rule override using cfgOverride["rt_lifetime_in_secs"] the token expiry is based on this value.
- If a value is defined for maximum_grant_lifetime, the refresh token expires when this limit is reached. This setting does not operate as a rolling window. The maximum_grant_lifetime is set during the initial access and refresh tokens generation.
definition:
...
token_settings:
issuer: https://www.ibm.com
signing_alg: RS512
signing_keystore: rt_profile_keys
signing_keylabel: httpserverkey
authorization_code_lifetime: 300
access_token_lifetime: 7200
id_token_lifetime: 3600
refresh_token_lifetime: 64800
maximum_grant_lifetime: 100000
- When enable_fault_tolerance is enabled, ROPC flow is run to generate Access token(AT1) and Refresh token (RT1) are generated. Subsequently, when refresh token flow is run, Access token(AT2) and Refresh token (RT2) are generated. The lifetime of RT1 is set to the value in seconds, configured by refresh_token_fault_tolerance_lifetime. If the remaining lifetime of the token is less than the value defined in refresh_token_fault_tolerance_lifetime, the lifetime will not be modified.
definition:
...
features:
enable_fault_tolerance: true
refresh_token_fault_tolerance_lifetime: 3600
enable_dynamic_registration: true
consent_prompt: NEVER_PROMPT
fapi_compliant: false
enforce_par: false
- If none of the above settings are configured, the definition configuration refresh_token_lifetime is used to set the lifetime.
definition:
...
token_settings:
issuer: https://www.ibm.com
signing_alg: RS512
signing_keystore: rt_profile_keys
signing_keylabel: httpserverkey
authorization_code_lifetime: 300
access_token_lifetime: 7200
id_token_lifetime: 3600
refresh_token_lifetime: 64800
Recommendation
When enable_fault_tolerance is enabled, since database is going to store additional entries, the refresh_token_fault_tolerance_lifetime value should be set to a smaller value in seconds, to reduce the load on the database.
Updated 3 months ago