Monthly Archives: October 2016

Access Token, Refresh Token

Since access tokens are so powerful yet also so potentially insecure, their risk is mitigated by giving them short-lived expiration windows.

Hence an access token returned by Azure iOS client framework will last for 1 hour. Within that hour, you can access data from your Easy Table. After an hour, you will get an authentication error.

However, this introduces another difficulty for web programmers — how to continue to access data on behalf of your users when their access tokens expire? Enter refresh tokens.

Refresh Token

What is a Refresh Token?

A Refresh Token is a special kind of token that can be used to obtain a renewed access token. An access token allows accessing a protected resource (i.e at any time.

You can keep requesting new access tokens until the refresh token expires.

Refresh tokens must be stored securely by an application because they essentially allow a user to remain authenticated forever.

How Refresh Tokens work

An Access Token is required to access a protected resource. Thus, a client will use a Refresh Token to get that Access Token, which is issued by the Authentication Server.

Although Access Tokens can be renewed at any time using Refresh Tokens, they should be renewed when old ones have expired, or when getting access to a new resource for the first time. Refresh Tokens can also expire but are rather long-lived. They are usually subject to strict storage requirements to ensure they are not leaked. Nevertheless, they can be blacklisted by the authorization server.

A Refresh Token is used to obtain new Access Tokens (and access protected resources) until it is expires (which may take a long time).

Access Tokens must also be kept secret, but due to its shorter life, security considerations are less critical.

In the case of Azure Active Directory refresh tokens

When refresh tokens were first explained to me, I was told something along the lines that a refresh token is used to refresh an access token. The word “refresh” certainly implies that that is the case. When I thought about it this way I imagine the access token as a battery-operated toy with dead batteries. It is “stale”, and cannot be used. In order to “refresh” it you replace the batteries and now the freshened toy works again.

But that is not what a refresh token does. Access tokens do not become stale only to be refreshed later on and reused. Access tokens expire, never to be valid again. A refresh token is not tied to an access token. It is simply used to get a new, valid access token when you need it.

How do you know when your access token is not valid? By attempting to use it and having the OAuth provider reject it.

Azure AAD token notes

Please, correct me if I’m wrong:
– the first time end-user uses my xamarin app (google authentication), he gets a token that will expire in 1 hour, after that, he finishes use my app and closes it.
– Three hours later, he opens the app and tries to access data from an azure table (for example): in this case, now, his “old” token is expired so, using your code above, he gets a “new” refresh token and he is able to obtain his data from azure. Perfect.

And now, what happens? will this new refreshed token expire in one hour like the first one?
So, does he have to get a new one in 72-hours? And so on with the cycle?
If not, “a fresh re-auth by the end-user will be required to get a new, non-expired authentication token”?

cgillum says:
May 25, 2016 at 9:31 am
Your understanding is correct. Refreshed tokens will have the same lifetime as the original tokens (1 hour in the case of Google). The tokens can be refreshed at anytime before or within the 72-hour window without requiring a re-auth. This will be a regular cycle within your app.

When the Access Token expires, you can use the Refresh Token to get a new Access Token. This Access token, along with the 1st access token, all expire in 1 hour. You can continue to use refresh token to request access tokens. The standard request token expiration date is 14 days. After 14 days, you need to sign in again.

Refresh Token for Azure Active Directory

30 Days of Zumo.v2 (Azure Mobile Apps): Day 7 – Refresh Tokens

Getting the key from your Azure AD Portal

Go to your Azure Active Directory Portal via

Sign in, and click on Active Directory, then you should be able to see your app.


Click on Applications, then your app name


In the next screen, click on Configure, then scroll down the page


Under ‘Keys”, select a year, and then save. You will then see the secret key appear. Copy that into test.js under the other global variables.


Save your client ID, and your key because we will be using it later.

Configured the Azure AD service to use refresh tokens

Log into your portal, select your app, scroll down to Resource explorer. You’ll see the next blade have a Go link. Click on the go link.


A separate page will appear with a lot of resource data. On the left hand side of the window is a tree explorer of your app’s resources. Expand the tree menu config and then authSettings.

Because this is a dangerous place, it’s set to read-only mode.

Click on the grey Read/Write box at the top of the screen, then click on Edit next to the PUT button.

I need to set two things. Firstly, the key that I created in the Azure AD portal needs to be copied into the clientSecret field as a string. Secondly, I need to set the additionalLoginParams to [“response_type=code id_token”], like this:


Also make sure the client ID matches from your Active Directory management portal from above.

Install Azure iOS SDK (framework)


First, unzip the framework. Drag the framework into your project.

Then, you may get a
undefined symbols for architecture arm64 MSLoginView

Go to your Project, click on General, scroll down to Linked Frameworks and Libraries, and add WebKit.framework as Optional.