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.
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 https://abc-123.azurewebsites.net/TodoItems) 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”?
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.