Around this time last year, my colleague Byron Tardif authored a post introducing Azure Websites Authentication/Authorization. This feature enabled users to quickly protect a site using Azure Active Directory with just a few clicks. We’ve heard a lot of great things about the ease of use, but many customers wanted more flexibility, particularly around API scenarios.
Then in March, we introduced Azure App Service, which brought together Web Apps, Mobile Apps; API Apps, and Logic Apps in a single offering. This included the App Service gateway, which allowed shared authentication among sites and expanded upon the login support from Mobile Services. However, one key request we heard from customers was for greater flexibility in authentication at the individual application level.
Today, we are merging these approaches and expanding the Authentication/Authorization feature of App Service to include new identity providers, new sign-in options, and greater flexibility in access control. This gives customers all the richness of the gateway, but on a per-site basis and with an improved management experience. We recommend web and mobile applications use this feature instead of the App Service gateway going forward.
Getting started
App Service Authentication/Authorization is exposed in the Azure Preview Management Portal. To enable it, navigate the the Settings blade of any Web or Mobile App and select Authentication/Authorization. Flip the switch to On to view the options for protecting your site.
One of the main changes is we have expanded the provider selection to include not only Azure Active Directory, but also Facebook, Google, Microsoft Account and Twitter. Clicking on any one of these options will allow you to configure settings that enable users to login with that provider. The Facebook and Microsoft Account blades also expose a list of optional scopes you can request at login time which enable your application to get more information about a user.
We offer multiple modes for AAD, and you can choose to use the Express options to get configured with just a few clicks. If you prefer, you can provide AAD configuration manually using the Advanced option. For more details about configuring each of the providers, please see our Azure Active Directory, Facebook, Google, Microsoft Account, and Twitter topics.
Deferred authorization
Many applications have varying access restrictions for different parts of the application. Perhaps you want some APIs to be publicly available, while others require sign-in. The original Authentication/Authorization feature was all-or-nothing, with the whole site requiring login. This option still exists, but we also allow your application code to render access decisions. Right now, this is best accomplished with ASP.NET sites, as we set the ThreadPrincipal with the user information if authenticated. Then your application can use the [Authorize] attribute on any actions that need protection, while others are allowed through. Applications using other platforms will want to use the full site protection option or manually validate the cookie or token.
When you enable Authentication/Authorization, the application code is in charge of access decisions by default. If you wish to have the site redirect all unauthenticated traffic to a particular provider, select that provider from the Action to take when request is not authenticated dropdown.
You can choose to configure multiple identity providers at a time, but only one can be configured for full site protection. Most applications using multiple providers will want to use the “No action” option for unauthenticated requests so the application can decide when and how to sign in the user.
Sign-in options
The original Authentication/Authorization only allowed login by redirecting the browser when an unauthenticated request reached the site. Now, developers can either leverage this behavior or explicitly start a login flow.
Your application can trigger the same redirect itself by navigating the user to the /.auth/login/ endpoint of your site, where is one of aad, facebook, google, microsoftaccount, and twitter. This option is perfect for sites featuring a login button and for many mobile applications.
Alternatively, a client can obtain a token using a provider SDK and exchange it for a session token. Simply submit an HTTP POST to the same endpoint with the provider token in a JSON body under the key “access_token” (or “authenticationToken” for Microsoft Account). This is the preferred solution for mobile applications if a provider SDK is available on the platform, and it also works for many web and API applications.
In fact, this support also means that App Service can allow headless authentications. If you have a daemon process or some other client needing access to APIs without an interface, you can request a token using an AAD service principal and use it for authentication with your application. In the case of AAD, we even allow you to bypass the session token and just include AAD tokens in the Authorization header, according to the bearer token specification.
As of an update happening today, the Mobile Apps client SDKs now support both of the aforementioned flows in the LoginAsync() methods.
Token Store
One other option you’ll note in the portal is the ability to enable or disable a token store. This feature allows underlying provider tokens to be stored in your application, accessible only when in the context of the associated user. This option is currently on by default and is required for mobile scenarios.
In order to retrieve additional user information as well as any tokens required for graph calls, simply issue a GET to the /.auth/me endpoint on your site. If the request includes a valid session cookie or session token, information about the current user will be returned. The Mobile Apps server SDKs provide a GetAppServiceIdentityAsync() method to easily consume this API.
Go forth and authenticate
With that, you should have everything you need to get started with authentication in your App Service applications. We’ll be working to expand our documentation set relating to this feature and its APIs, so check back here for additional feature improvements as well.
We hope you will give App Service Authentication/Authorization a try and let us know what you like or don’t. You can always reach the team on the Azure feedback site and MSDN forums, or you can leave a reply in the comments below.