Skip to main content
Paid Feature

This is a paid feature.

You can click on the Enable Paid Features button on our dashboard, and follow the steps from there on. Once enabled, this feature is free on the provided development environment.

Reuse website login for desktop and mobile apps

This pattern is useful if you want to have the same web authentication experience for your desktop and mobile apps. The flow will allow you to save develpoment time but you will have to keep in mind that it will not involve a native authentication interface. Users will be directed to a separate browser page where they will complete the authentication flow.

Reuse website login for desktop and mobile apps

The authentication flow will work in the following way:

  1. User accesses the native application
  2. The user gets redirected to Authorization Service authentication url.
  3. The Authorization Service redirects the user to the login UI
  4. User completes the login attempt
  5. The Authorization Service backend redirects the user to the callback URL. This URL should be a deep link that can be opened by your actual application.
  6. The application uses the callback URL information to request a OAuth2 Access Token from the Authorization Service.
  7. The returned token is saved by the application.
info

This guide assumes that you already have setup and configured SuperTokens in your Authentication Service.

For more information on how to do that please check our quickstart guides.

1. Enable the OAuth2 features from the Dashboard#

You will first have to enable the OAuth2 features from the SuperTokens.com Dashboard.

  1. Open the SuperTokens.com Dashboard
  2. Click on the Enabled Paid Features button
  3. Click on Managed Service
  4. Check the OAuth 2.0 option
  5. Click Save

Now you should be able to use the OAuth2 recipes in your applications.

2. Create the OAuth2 Clients#

For each of your applications you will have to create a separate OAuth2 Client. This can be done by directly calling the SuperTokens Core API.

# You will have to run this for each one of your applications
# Adjust the client_name and redirect_uri based on that
curl -X POST /recipe/oauth2/admin/clients \
  -H "Content-Type: application/json" \
  -H "api-key: " \
  -d '{
      "clientName": "<YOUR_CLIENT_NAME>",
      "responseTypes": ["code", "id_token"],
      "grantTypes": ["authorization_code", "refresh_token"],
      "tokenEndpointAuthMethod": "none",
      "scope": "offline_access <custom_scope_1> <custom_scope_2>",
      "redirectUri": ["https://<YOUR_APPLICATION_DOMAIN>/oauth/callback"]
    }'
  • clientName - A human-readable name of the client that will be used for identification.
  • responseTypes - Specifies the types of responses your client expects from the Authorization Server. Most of the time, you would need the following two to be present:
  • grantTypes - The grant types that the Client will use.
  • tokenEndpointAuthMethod - Indicates that the process of obtaining an OAuth2 Access Token will not make use of the client secret
  • redirectUri - A list of URIs to which the Authorization Server will send the user-agent (browser) after completing the authorization step. These can be deep links to mobile or desktop apps as well, but they must be exact URLs, without wildcards.
  • scope - A space separated string of scopes that the Client will request access to.

If the creation was successful, the API will return a response that looks like this:


{
    "clientName": "<YOUR_CLIENT_NAME>",
    "clientId": "<CLIENT_ID>",
    "callbackUrls": ["https://<YOUR_APPLICATION_DOMAIN>/oauth/callback"],
}

Based on the client creation process we can also infer two additional values that we will need later on:

  • authorizeUrl corresponds to <YOUR_API_DOMAIN>/auth/oauth/auth
  • tokenFetchUrl corresponds to <YOUR_API_DOMAIN>/auth/oauth/token
caution

You will have to save this response because we do not persist it internally for security reasons. In the next steps we will use the values to complete several configurations.

Change the default token lifespan#

By default, the tokens used in the authorization flow will have the following lifespans:

If you want to change the default values you need to specify additional properties in the Client creation request body. Use string values that signify time duration in milliecoseconds, seconds, minutes or hours (e.g. "2000ms", "60s", "30m", "1h"). There are no limits on the duration of each token.

  • OAuth2 Access Token - Set the authorizationCodeGrantAccessTokenLifespan property.
  • OAuth2 ID Token - Set the authorizationCodeGrantIdTokenLifespan property.
  • OAuth2 Refresh Token - Set both the authorizationCodeGrantRefreshTokenLifespan and the refreshTokenGrantRefreshTokenLifespan properties to the same value.

3. Make sure that you have properly configured the Authorization Service#

If you have not set up the Authorization Service yet, please check one of the previous guides based whether you use multiple backend service:

4. Update the login flow in your applications#

In each of your individual applications you will have to setup up logic for handling the OAuth 2.0 authentication flow. We recommend using a generic OICD or OAuth library in order to do this.

You can use the react-native-app-auth library. Just follow the instructions to setup your application.

The configuration parameters can be determined based on the response that we received on step 2, when we created the OAuth2 Client.

  • issuer corresponds to the endpoint of the Authorization Service <YOUR_API_DOMAIN>/auth
  • clientID corresponds to clientId
  • redirectUrl corresponds a value from callbackUrls
  • scopes corresponds to scopes

You will also need to set the additionalParameters property with the following values:

  • max_age: 0 This will force a new authentication flow once the user ends up on the Authorization Service frontend.
  • tenant_id: <TENANT_ID> Optional, in case you are using a multi tenant setup. Set this to the actual tenant ID.
info

If you want to use the OAuth2 Refresh Tokens make sure to include the offline_access scope during the initialization step.

5. Test the new authentication flow#

With everything set up, you can now test your login flow. Just use the setup that you have created in the previous step to check if the authentication flow completes without any issues.

Looking for older versions of the documentation?
Which UI do you use?
Custom UI
Pre built UI