Azure App Service's Authentication / Authorization feature has made enabling app authentication extremely simple, whether you are working with client flow or server flow. Still, if you've worked with token-based authentication in the past, token expiry and refresh can be a hassle. Depending on the authentication provider, token expiry can range widely from minutes to months. Facebook has a 60-day expiry, while other common providers like Google, Azure AD, and us at Azure Mobile Apps have a 1-hour expiry. You probably had to handle these in your codes to ensure app user authentication and client experience, similar to what Adrian Hall detailed in his 30 Days of Azure Mobile Apps: Day 7 – Refresh Tokens post.
To simplify this token refresh experience, we recently baked Auth 2.0’s Refresh Token into Authentication / Authorization’s client SDKs! Instead of adding your own refresh logic for authentication, here’s how you can use the built-in token refresh feature in our Managed Azure Mobile Client SDK 2.1.0. or later versions to keep app users logged in.
This feature is only available for server-managed authentication flow. And given the balance between security and an app's possible inactivity during the weekend, refresh tokens can be obtained as long as the Mobile Apps authentication token has not expired for more than 72 hours (see Chris Gillum's post for more details).
How to Use Refresh Tokens with Your Identity Provider
We assume that you have successfully set up desired identity providers with your Mobile App following how-tos for Microsoft Account, Google, or Azure Active Directory (Facebook and Twitter are not supported).
Microsoft Account
Enable wl.offline_access scope on Portal > Settings > Authentication / Authorization > Microsoft Account:
Then the following snippets will help you refresh users in a server-managed authentication workflow:
MobileServiceUser user = await client.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount); //... user = await client.RefreshUser();
In server-managed authentication workflow, pass in additional parameter (access_type=offline) in MobileServiceClient.LoginAsync().
MobileServiceUser user = await client.LoginAsync(MobileServiceAuthenticationProvider.Google, new Dictionary() {{ "access_type", "offline" }}); //... user = await client.RefreshUser();
AAD
After configuring your AAD client secret on Azure Resource Explorer (see the Azure Resource Explorer snippets here if you don't know how) [UPDATE 9/22: you can now configure your AAD client secret in Portal > Settings > Authentication / Authorization > Azure Active Directory], pass in an additional parameter in MobileServiceClient.LoginAsync() in your server-managed authentication flow.
MobileServiceUser user = await client.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, new Dictionary() {{ "response_type", "code id_token" }}); //... user = await client.RefreshUser();
Handling Refresh Failures
RefreshUser would work only if all following requirements are satisfied:
- The identity provider supports OAuth 2.0’s Refresh Token. Microsoft Account, Google and Azure Active Directory support Refresh Token, while Facebook and Twitter do not.
- Permission/scope required for using Refresh Token is granted by the developer, e.g. wl.offline scope for Microsoft Account, offline access_type for Google account, code reponse_type for Azure Active Directory account.
- Access token or refresh token is not revoked by the developer.
- MobileServiceAuthenticationToken has not expired for more than 72 hours.
Here are some errors that you can be experiencing with the refresh call.
Error |
Why? |
What to do? |
400 Bad Request |
|
Prompt user to login again |
401 Unauthorized |
|
Prompt user to login again |
403 Forbidden |
|
Prompt user to login again |
Give it a try and let us know what you think!