Back to blog home page

Single Sign-On with Azure Active Directory and Backand

Posted by on Jan 11, 2017

Most internet users have accounts with many different service providers. As these providers have grown, they have also opened up their authentication systems to third-party developers. By leveraging these authentication systems, third party apps can reduce their scope and complexity, offloading user registration, verification, and authentication to a package solution like Google Plus, Github, Facebook, or Azure AD (Active Directory).

Building on this functionality, many providers offer Single Sign-On (SSO) functionality. Below we’ll look into SSO as a concept, dive deep into Microsoft’s Azure Active Directory SSO process, and finally touch on integrating this process into your Backand application. 

What is SSO?

Single Sign-On, or SSO, is a mechanism allowing a user to sign into one application then leverage that authentication to access other auth-restricted applications without having to log in again. Applications that implement SSO with a provider use token data stored on the user’s machine to check the user’s authentication status within their system. Your app can then leverage this existing session to authenticate the user, allowing your app to uniquely identify the visitor and present all restricted information as appropriate.

While the above explanation is fairly dry, the following use case helps provide color:

  1. As a user, I sign into Office365.com to use some Microsoft Office functionality.
  2. After working, I switch tabs to a different application.
  3. This application sees that I logged in to Office365.com, and obtains my login status from Microsoft.
  4. If my login is valid, the application skips validation and takes me directly to the content I was looking for.
  5. If my login is invalid, I am prompted to sign into Microsoft again.

With this process, your users are able to access your app immediately. Your application handles checking configured providers for SSO status and re-authentication as appropriate, reducing the total number of times that a user has to log into your application, increasing both usability and security.

SSO with Microsoft’s Azure Active Directory

Microsoft’s Azure AD extends local Active Directory functionality into the cloud, allowing users to re-use their organization’s login credentials across a suite of applications. While the authentication and registration management alone is quite powerful, the majority of the utility for Azure AD is in their Single Sign-On functionality. Azure AD offers three different ways to authenticate with applications using SSO:

  • Federated Single Sign-On: With Federated Single Sign-On, your application redirects users to Azure AD for authentication instead of prompting your user for a username and password. This is the richest SSO mode and supported for apps that work with SAML 2.0, WS-Federation, or OpenID Connect specifications.
  • Password-based Single Sign-On: Password-based Single Sign-On uses a web browser extension or mobile app to enable secure password storage and replay. While this leverages an existing sign-on process within an application, it allows the user credentials to be managed by an administrator. These credentials are then no longer required by the end user – they don’t even need to know the password.
  • Existing Single Sign-On: Existing Single Sign-On allows you to tie existing Single Sign-On systems into Microsoft Azure AD or Office 365. This allows you to quickly integrate your existing SSO provider with an Azure AD-powered system and provides additional reporting on the authentication process.

Depending on your usage scenario, any of the above systems can provide a quick and easy SSO integration for your application. In the remainder of this post, we’ll focus on Federated Single Sign-On.

Integrating Federated Single Sign-On with Backand

Integrating Federated SSO with a Backand application is a fairly straightforward task. There are three scenarios relevant to implementing Federated SSO in your app:

  1. The user is not registered with your SSO provider
  2. The user is registered with your SSO provider, but not logged in
  3. The user is registered and logged in with your SSO provider

For the first scenario, the user not being registered with your SSO provider so you don’t have much to do. If the provider doesn’t offer registration, or if you do not want to permit unregistered users, simply direct the user to an error page detailing how to register for your application.

The second and third scenarios, despite having different starting points, have exactly the same sequence of steps:

  1. Redirect your user to Azure AD for authentication.
    A) If the user has previously logged into your application before, you can simply re-use a previous authentication token during this step to short-circuit the process.
    B) If the user is not currently logged into Azure AD, they will do so on Microsoft’s servers at this point.
  2. Once authentication is complete, Azure AD responds with results of the sign-on attempt and a security token. Simply verify the security token to authenticate the user.

This process is simple and straightforward but has a lot of hidden power. By storing the security token returned from the auth call in step 2 (in accordance with the terms and conditions of your SSO provider), you can now quickly re-authenticate your users every time they access your application by simply re-verifying the security token.

The above steps represent an assertion of trust between your application and Microsoft, and as such cannot be conducted in isolation. Prior to successfully implementing SSO, you’ll need to register your application with Azure AD via the Azure AD portal. Review Backand’s documentation on how to register with Azure AD. Additionally, Microsoft provides an excellent high-level overview of Azure AD SSO options on their website.

Managing SSO Users

Once you’ve got the guts of an SSO implementation running, you need to add user bookkeeping and tracking by creating a user account in your application. This is used to manage things like permissions for your application, content ownership, and other user-specific functionality. Simply implement a means to relate SSO user logins to the relevant user account data, and your users are ready to work!

One bit of complexity that could arise is in supporting multiple SSO providers. Using the Federated SSO model presented above, you’d need to implement a means by which a user is assigned a “preferred” SSO provider, which is used to drive authentication whenever that user accesses your application. Another option is to use a solution like Azure AD’s Existing Single Sign-On, which allows you to essentially transition your application’s authentication to a third party using the same Azure AD endpoints you typically use to authenticate your users. You can manage these links using the Azure AD portal’s access panel.

Conclusion

SSO is a powerful tool through which you can increase both the usability and the security of your application. By offloading the mechanics of the authentication process to a third-party, you can easily integrate your application into an existing user ecosystem like Microsoft’s ActiveDirectory, making your Backand application a first-class partner in your organization’s ecosystem. Furthermore, using similar tools you can integrate with any number of SSO providers, giving your users the ultimate flexibility to manage their own security profile within a secure application. Which approach is best will depend largely on your use-case.

  • Bennett Fonacier

    Can I use AWS resource with the SSO?