OAuth - Part 2: Illustrated Use Case

edited December 2022 in Best Practices

Now that we are more familiar with the concept of OAuth, let’s see it in action.

Adding a new way to connect to Anaplan and get an access token

Now that we know more about the Refresh Token, we can imagine a customized script using OAuth information for as long as the token remains valid.

In those scenarios, you might want to use the Device Grant type. It requires less information than the Authorization Grant flow, as the client_secret is not needed.

  • One can argue that CA Certificates will not be needed anymore. Compared to OAuth token usage, their remaining edge lies mainly in the lifespan of the CA Certificate information, which can last up to 3 years.
  • A "perpetual" refresh token will last up to 1 year.
  • Also, there will be no need to maintain an OAuth client when using CA Certificates.

Let's see a step-by-step sequence on how to get this refresh token. We will be using Postman for that.

Getting a refresh token via the Device Grant type

  1. Create the OAuth Client - follow the steps described here

Put valid syntax in the "Allowed callback URLs", more details here.

  1. Once it's created, change the Refresh Token behavior to "Non-Rotatable" and save.


  2. Use the copy button to copy the client ID
  3. Open Postman and execute this simple POST request

annejulie_2-1643992371948.pngThe response will give us:

  • device-code: keep it, you'll need it later
  • verification_uri_complete: the URL you'll use to verify your device code
  • expires_in: this is the time you have to verify your device code
  1. Copy the address in the verification_uri_complete tag and open a browser with it:


  • This screen asks for a user's intervention to validate the device code. Press Confirm.
  1. You'll get a pop-up message asking you to validate the authorizations you want to give to that client.


  • Click on the green tick and you will get the congratulations message:
  1. Go back to Postman and by using the device_code and the client_id you've generated in the earlier steps, perform this POST request:
  • In addition to an initial access_token, you have generated the refresh_token we were looking for.
  1. Now, as long as the refresh token is valid, you can use it to generate a new access_token by running this simple POST request:
  • annejulie_7-1643992372041.png

Using this refresh token with an example

Now that we have a refresh token, let's illustrate it with a custom script that needs to get a token from Anaplan.

In the example below, we have a custom script that is mainly based on using Anaplan APIs.
With this script, you can initiate the connection of the application with the regular basic authentication or CA cert information.

A way to trigger this script is by using basic authentication in the command line (it's the same way to authenticate as with Anaplan Connect):


Note: the service has been successfully launched as a token has been generated.

But we also added the possibility to use the refresh token to avoid either the use of basic authentication or CA Certificate information as you can see below:


Storing tokens can be considered less critical than actual credentials.
Deactivating a token can be an external team's task and doing it will not impact the actual user's credentials it is linked to. There won’t be a need to change the password.


In summary, you now know a way to use this refresh token in your future scripts and interactions with OAuth. This will enable you to push even further your interactions between Anaplan and third-party systems.


Next, let’s have a look at Part 3: OAuth and Third-Party Applications.


Got feedback on this content? Let us know in the comments below.

Contributing authors: Joey Morisette and Christophe Keomanivong.