Rate this page


Sessions allow the Data Governance Broker to act as a single sign-on (SSO) service that can be shared by multiple applications, which do not need to process user logins themselves.

Data Governance Broker sessions

When an end user logs in to the Data Governance Broker, a session is created for that user and is persisted to the user’s entry at the user store. The session is tied to the user’s web browser using a session cookie. Given any one user logged in to the Data Governance Broker with multiple applications running in the same browser, the Data Governance Broker will report the same authentication state to each application.

Data Governance Broker sessions represent the authentication state between users and the Data Governance Broker. They do not represent an authentication state between users and applications. If an application has received an ID token from the Data Governance Broker, then it can be satisfied that the user has authenticated, and it may correlate the subject of the ID token with data of its own, and it may establish an application session of its own on that basis, if need be.

Sessions may be contrasted with access tokens, which represent the authorization state relationship between applications and the Data Governance Broker. As long as an access token is valid, the application in possession of the access token can make resource requests. If the access token is revoked or expires, then the application can no longer make these requests. The session, however, is not directly connected to this. For example, revoking an access token does not end a user’s session.

A user’s session may be ended in one of two ways, each with different side effects:

  • By invoking the Data Governance Broker’s logout endpoint. This will terminate the user’s session and revoke all access tokens issued on behalf of the user.
  • By performing a DELETE operation using the Session Management SCIM API. This will terminate the user’s session only.

Application sessions

If and how an application uses its own session mechanism is up to the developer. Bear in mind that OAuth 2 and OpenID Connect rely on browser redirects to transfer request and response data between an application and the server, and the client is expected to validate that certain request values were correctly returned by the server — namely, state and nonce. So a client will generally need some kind of temporary persistence mechanism tied to the current user.

Because the Data Governance Broker is a single sign-on service, invoking its logout endpoint causes the user to be logged out globally, for all applications. When an application maintains its own session independently of the Broker’s session, the application may prefer to provide a logout feature that applies specifically to its session. In that case, the application should also call the Data Governance Broker’s token revocation endpoint to dispose of its access token. This has no effect on the user’s Broker session, but ensures that the access token is no longer usable, since it is no longer needed.

ID token as session mechanism

Applications often use cookies as a handle to in-memory or database-persisted sessions. An alternative that can be considered is to keep all session information on the client, either using WebStorage or a cookie.

The ID token received from the Data Governance Broker could be stored as the value of a cookie. Before performing any action requiring an authenticated user, the application could check the ID token’s exp claim to determine if the user’s authentication state is still valid. If it is not, then the application could make an OpenID Connect request to the Data Governance Broker to receive a new ID token.

Advantage of this method include:

  • The application is able to avail itself of the user’s Data Governance Broker’s session for its own purposes, overcoming many of the caveats listed above.
  • Maintaining session state in the application backend also becomes unnecessary, potentially enhancing the application’s scalability.

Disadvantages include:

  • The user may log out from the Data Governance Broker while the ID token is still active. The application will not receive an update on the user’s authentication state until it makes another OpenID Connect request. This can be mitigated by configuring ID tokens to expire after a short interval. The default validity period is 15 minutes.
  • The ID token must be validated scrupulously to prevent tampering. In particular, this must include signature verification.
  • If the ID token includes claims with sensitive values, then it must also be encrypted by the Data Governance Broker and decrypted by the client.
  • This is a relatively new session pattern, and its security aspects must be carefully considered.

Access token as session mechanism

Some applications do not actually need to use OpenID Connect for authentication because they don’t actually keep track of the user’s login state. These applications tend to be simple resource server clients: They use OAuth 2 to obtain an access token for delegated access to a user’s data, and then they use the access token to make resource requests. When the access token is obtained, a user might have to authenticate, but this is essentially a side effect of the authorization process from the application’s perspective.

In such cases, the access token can be considered a kind of session mechanism. As long as the access token is valid, the application uses it. If the resource server rejects the access token, then the pseudo-session is over; the application must make another OAuth 2 request to obtain an access token before continuing.

If you decide to use this pattern, just bear in mind that you must not use the access token as proof of user authentication. An access token is only to be used for data access from a resource server. This pattern is most appropriate when all data used by the application is accessed using the access token, ensuring that all access control is handled by the resource server.