Skip to main content
Authorization Code flow is the best flow to use for web applications. When it was first introduced Authorization code flow required the client_secret. However, on a windows or mobile application that causes security problems. Proof Key for Code Exchange (PKCE) (rfc7636) was introduced as extra layer of security on top of Authorization Code flow, and provides a way for native applications to use Authorization Code flow without exposing the client_secret in a vulnerable way.
PKCE does not replace the use of a client secret for all scenarios, and in fact PKCE is recommended even when a client is securely using the client secret.
OAuth is about enabling users to grant access to applications, and allowing those application access to their SuperOffice web services. The Authorization Code flow begins when a client application redirects a user to the authorize endpoint.

Authorization Code flow parameters

The user is then directed to the SuperOffice SuperID sign-in screen, where they enter their credentials. An identity provider authenticates the user and asks for consent to access their resources on behalf of the Relying Party (app).

Redirect back to the application

When successfully authenticated and consent given, SuperID sends a response that redirects the user agent back to the Relying Party (app) redirect_uri. The response includes an Authorization Code and any state provided by the client earlier.

Authorization Code response

Exchange the authorization code for an access token

This is the final step, where the Relying Party (app) requests an access token.

Authorization Code request

The identity provider (central-superid) will verify all the parameters, ensuring the client ID and secret match and the code hasn’t expired. When that’s complete, it will generate an access token and send it in the response.

Post response

The application now has an access token and can start making API requests to the SuperOffice tenant web services. Certified OpenID Connect libraries automatically verify the id_token. If your application doesn’t use a certified library, read how to validate the id_token JWT. With a verified id_token the application can safely store the refresh_token for fetching a new access token when the current expires. The Authorization Code flow is complete!

Refresh token

When an access token has expired, refresh tokens are used to get a new access tokens without forcing the user to go through the Authorization Core flow again.
No other flow, only the Authorization Code flow, returns a refresh token.
The refresh token is only used:
  • when the access (or ID) token has expired
  • when there is a need to update the claims in an ID token
Refresh tokens must never be stored client-side in the browser!
This is a long-lived token that is a contract between an application and tenant user. It can be re-used:
  • for the lifetime of the application, or
  • as long as the application authorization record (consent) exists, or
  • until it has been revoked - tenants can revoke authorizations
Refresh tokens may be revoked if we suspect its security has been compromised, or a customer or application vendor requests it be revoked.

Send a refresh_token request

A refresh_token is used in a POST request sent to the tokens endpoint.
Refresh token parameters:

Receive a refresh_token response

The response contains the token type, access token, expiration in seconds, and id token.