Quick Links

Single Sign-On (SSO) provides much-needed convenience and intrinsic security to sign-on activities for applications. Fortunately enough, SSO works with any web app in your Azure Active Directory, so let's take a look at how we can set it up.

With SSO, your users will sign in once with a single account and have access to your web applications, SAAS, company resources, and domain-joined devices. After signing in, they can launch any application from the Azure AD MyApps and/or Office 365 Portal. Admins can manage user accounts, and add/remove access to applications based on membership.

Without SSO, your users have to remember app-specific log information and sign into each. The staff has to update, create, and manage accounts for each application. Users have to remember the passwords and spend their time on signing-in.

So, it's not hard to see that SSO is a clear winner when it comes to accessibility on the web. But it's not only convenient, it's secure, so let's take a look at OpenID Connect.

What Is OpenID Connect?

Even though Security Assertion Markup Language is the current primary SSO solution for enterprises, many are resolving their use to OpenID connect for many reasons.

Here are some to name a few:

  1. Works better on mobile devices
  2. Based on OAuth 2, therefore easier for developers
  3. Perfect for non-employees
  4. Easy to configure, and affordable to sustain
  5. Industry Standard for Azure Active Directory, Okta, Google G Suite, Auth0, OneLogin, etc.

OpenID Connect is native to many IDPS, namely the Azure AD, which is why we will be making use fit.

Both OIDC and SAML can run together. So, if you need to separate and categorize your external and internal users that might be the solution. It's also good for separating your solutions, where you use SAML for employee access and OIDC for card embedding on other sites.

Even if both methods are applied, DSO can still be employed, but that's not really used in this scenario.

How to Add an OpenID App from Azure AD?

In order to start the process of enabling SSO for your apps, you need to:

  1. Access the "Azure Portal," and select the "Azure Active Directory."
  2. Navigate to "Enterprise Applications," then to "All Applications."
  3. Select the "New Application" button, and type in the name in the search box. (OpenID and OAuth have the Add button disable by default. Your tenant admin should select the sign-up button, and provide access to the app.
New Application signup.
  1. After successful authorization, you can accept the consent, and then the Application Home page will open up.
  2. When you select the sign-up button, you will be redirected to the "Azure Active directory" to fulfill the sign-in credentials.

At this point, you have provisioned access to the tenant for the OpenID solution for that specific app.

You can only add a single instance of an application. If you have already done so and tried to request consent, it will not be added to the tenant again. One app instance per tenant, that's the only way it works.

How Authentication Will Work with OpenID Connect

In order to continue with SSO authentication, you have to first understand how a simple sign-in flow works:

  1. User signs in and enters credentials, then consent to permissions. (This is run through the /oauth2/authorize command.)
  2. An id_token is returned, and the authorization_code is sent to the browser.
  3. A redirect occurs to the URL.
  4. The id_token is validated;, a session cookie is set.
  5. OAuth code bearer is requested to provide authorization_code.
  6. The token is returned with refresh_token.
  7. Web API is called with a token in the Auth header.
  8. The token is validated.
  9. Secure data is returned to the Web Server App.

This is a very simple representation of the authorization flow, and that's what it really comes down to in the end.

In order to develop a native client application or multitenant web app, you can use the Azure AD consent framework. This will allow sign-in from user accounts of a certain Azure AD tenant, which has been provided with access in the former steps.

Access to web APIS might be necessary. For instance, the Microsoft Graph API to access Azure AD, Office 365, or Intune. Also, any personal web APIS will need to be granted access from the tenant.

The consent framework is based on an administrator or prior user providing consent to an application that is requesting registration in the directory. It might involve directory data access, but it doesn't have to. After consent has been provided, the application will contact the Graph API on behalf of the user and access the information as necessary.

The API provides access to various data points, but it also provides access to groups and users in the Azure AD and any other Microsoft cloud services. Therefore, it will work with any of your web applications.

This is how the consent experience will occur for the user and developer:

A web client application needs permissions to access a resource. The Azure portal is declaring a permission request to set a configured time. Like any other configuration setting, it becomes part of the Azure AD registration data points.

To access the permission path, you need to click on "App Registrations" from the left side, and open the application you will be working with. Then you can navigate yourself to the "API Permissions" menu, and select an "Add A Permission" option. After this, you select the "Microsoft Graph," and choose the options from the "Application & Delegated Permissions."

 

 Access permission path by clicking "App Registrations," opening your application. Navigate to "API Permissions" menu, select "Add A Permission" optio.

Now, the permissions have been updated, the user is about to use SSO for the first time. The application first needs to receive an authorization code from the endpoint in Azure AD, then the code will be used to access a refreshed token. If the user has not been authenticated, the endpoint will prompt a sign-in.

After they have signed in, Azure AD will determine if the user needs to be shown a consent request. The decision will be based on the group that has been granted to the user.

Consenting to variou permissions.

If consent was not granted, a prompt will appear and display the permissions that it requires for functionality. A user can consent to various permissions, but others might need access to a tenant administrator account.

Conclusion

Even though the process behind enabling OpenID Connect is quite simple, the functionality and application of SSO will be stringent upon the capacity of the developer who will be in charge of implementing the function.

OIDC does come with a variety of integrated plug-ins that allows instant access from the box, as mentioned via the basic authorization flow, but anything that requires a custom approach will be of a more involved approach.

For more information on how to extend the opportunity of SSO, read some of the original documentation from Azure.