OpenID Provider considerations

An OAuth Relying Party application can use a granted access token until expiration. The timeout for access tokens is the smaller of the timeout value under "Server Security" on the main page of the SSO Management console (See Figure 3 in page Timeout configuration - SSO) and the Application timeout value on the Application configuration page (See Figure 4 in page Timeout configuration - SSO).

If the timeout setting of an OAuth application is set to 0 in the Management console, the session and the access token issued will immediately expire at the time of issue and the access token will be rejected when used at the userinfo endpoint.
The use of the userinfo endpoint is optional and unnecessary if there are no user attributes.

If the userinfo endpoint is required, the minimum logical timeout value is one minute (value: 1).

If long term access to the userinfo endpoint is required, for example to allow for offline (user not present) e.g. rechecking of current user attributes on a weekly basis before sending an email message, this is available using a refresh token. Ubisecure SSO supports OAuth2 Refresh tokens and their management from the management console on a per RP basis.

In GSMA Mobile Connect deployments, refresh token use case is called offline_access in the PDATA.01 specifications. For security reasons, offline_access is an administrator mandated and controlled function and cannot be requested "on the fly" using scope without prior whitelisting and configuration.

A refresh_token is valid indefinitely until revoked. A revocation endpoint is provided for invalidating the refresh_token.

Relying Party considerations

Because OAuth authorization requests are unsigned, values contained in the request can be verified by the SSO server. It is important that the response received is verified by the application to ensure it meets the requirements of the request.

In use cases where single sign-on is not desired, to prevent SSO and ensure a fresh user session has been created, the relying party MUST use the OAuth2 "prompt" value of "login" when making a login request and MUST compare the iat and auth_time timestamps to the time when the request was made. If the auth_time is significantly less than the iat value (more than a few seconds), it indicates that the session is not fresh and should be rejected. Furthermore, use of a max_age value of 0 is recommended.

If the "prompt" value was "login" in the authorization request, the iat and auth_time timestamps should be almost the same. The iat time should be equal to or greater than the auth_time value.

In GSMA Mobile Connect configurations, no logout process is currently defined. When the user decides to terminate a Relying Party session, the Relying Party must securely end its own session. It is recommended to call the /uas/logout address and the revocation_endpoint endpoint should be called to invalidate any unnecessary tokens, especially in mixed mode installations where relying parties of various integration protocols (SAML2, WS-Federation) are used and Single Logout is desired.