Single Sign-On (SSO) using AWS Cognito and Azure AD

Single Sign-On (SSO) solutions allow users to enter credentials once and access many systems simultaneously. IT administrators can use a local SSO server or a third-party service to manage authentication, allowing for centralized access management. SSO solutions strengthen managerial abilities and are highly advantageous to fast-developing firms.

In this article, you’ll learn how to implement Single Sign-On on your application using AWS Cognito and AzureAD.

What is Single Sign-On (SSO)?

Single Sign-On (SSO) is a system that replaces several login windows for various applications with a single one. With SSO, users may access all their SaaS services by entering their login information once on a single page (username, password, etc.). Enterprises, smaller organizations, and individuals may all utilize SSO to make managing a variety of identities and passwords easier.

Like every other thing in life, utilizing a Single Sign-on authentication method has its advantages and disadvantages. One of the great things about SSO is that it allows users to remember and manage fewer usernames and passwords across several apps. On the other hand, the issue with SSO is that if users forget their credentials and cannot retrieve them, they are locked out of the various systems connected to it.

How does SSO work?

An SSO service generates an authentication token each time a user logs in to keep track of their verified status. An authentication token is a piece of digital data kept on the SSO service servers or in the user’s browser, similar to a temporary ID card given by the user.

Image credit: Double Octopus

The SSO service will do a check on each app the user accesses. The app receives the user’s authentication token from the SSO service and grants single sign-on access to the user. The SSO service will then prompt users to sign in if they haven’t already.

Since it does not maintain user identities, an SSO service may not always remember who a user is. Most SSO systems operate by cross-referencing user credentials with an additional identity management service.

How to implement SSO using AWS Cognito and Azure AD

AWS Cognito is a web and mobile app authentication, authorization, and user management service. With it, users can sign in using a username and password or a third-party service like Azure AD, Amazon, or Google. AWS Cognito has two main components; the User pools, a user directory that allows users to sign in, and the Identity pools, which give users access to other AWS services. The User pools and Identity pools can be used independently or jointly.

On the other hand, Azure Active Directory (Azure AD) is a cloud-based identity and access management (IAM) solution for enterprises. You can think of it as the backbone of the Office 365 system, which syncs with on-premise Active Directory and provides OAuth authentication to other cloud-based applications.

Azure AD will act as an identity provider (IdP), and AWS Cognito will act as a service provider (SP).

Before granting the user access to AWS services, AWS Cognito verifies the user’s rights with the identity provider while Azure AD checks user identification (e.g., emails, passwords) and asserts to AWS Cognito that the user should have access and that the user’s identity if it is legitimate. The Single Sign-On authentication is based on the following steps:

• The user visits an application, which sends them to an AWS Cognito-hosted website.

• AWS Cognito determines the user’s origin (by client id, application subdomain, and so on) and leads them to the identity provider for authentication. In our case, to the Azure Active Directory login page. This is a request for SAML authentication.

• The user is redirected to an SSO URL on their browser. The user either already has an active browser session with the identity provider or creates one by logging in. The identity provider (Azure AD) creates the authentication response in the XML document format, which could contain the user’s username, email address (and additional characteristics if set), and it is then signed with an X.509 certificate. The result is returned to the service provider (AWS Cognito) — This is the authentication response for SAML.

• The authentication response is retrieved and validated using the certificate fingerprint by the service provider, who already knows the identity provider and has a certificate fingerprint. With the access token in the URL, the user’s identity is confirmed, and the user is granted app access.

Now that you understand the meaning of AWS Cognito and Azure AD and how they work together, let’s get into implementing SSO with these tools. I’ve broken down the following section into different steps to help you understand the procedure a lot better.

Step 1: Create a Cognito User Pool on AWS

Create an AWS account to start with. Once created go to the AWS Management Console, navigate to the** “All Services”** section, and click on Cognito in the Security, Identity, and Compliance section.

On the Cognito page, click on “Manage User Pools” -> “Create a user pool” -> add the required information, and click on “Review defaults”.

On the Review page, you are given an option to update the existing attributes. In our case, we will update the email attributes, so click on the edit icon at the top-right corner of your screen.

Then select “Email address or phone number” as the user sign-in option, choose “Enable email addresses” from the subcategories, and click Next step.

Finally, click the “Create Pool” button to complete the pool creation process. By doing this, the pool should now be ready to use. Take note of your Pool ID (e.g., us-east-1 XX123xxXX), as we’ll need to use it later when setting up the Azure AD portal and mobile app settings.

The next thing we will do is set the domain name for our User Pool. To do this, click on “App integration” -> “Domain name” -> fill in the domain prefix -> “Save Changes”.

On clicking the “Save Changes” button, AWS will generate a domain for you. In my case, it was [https://example-setup-app.auth.us-east-1.amazoncognito.com](https://example-setup-app.auth.us-east-1.amazoncognito.com) and this domain will be connected to the user pool we had created earlier on.

Step 2: Create an AWS App client and include it in the User Pool

The next thing we will do is create an application using Cognito Service. To begin, go to your “User Pool” -> “General settings” -> “App Clients” -> “Add new app client”. Then add a name for your app client, select “Generate client secret” and click on the “Create app client” button.

Now, let’s install the App Client by clicking on “App integration” -> “App Client Settings” -> “Select your mobile client app” -> configure the settings ***following the format in the image below -> “Save changes*”.

Step 3: Create an Azure AD enterprise application & connect it to the Cognito User Pool

To do this, go to the Azure portal, click on “All services” *and search for *“Azure Active Directory (Azure AD)”.

On the Azure AD page, click on “Enterprise applications” -> “New Application” -> “Non-gallery application” -> Type in the name of your application and click on the Add button.

Now that your application has been developed, it’s time to link it to the AWS User Pool. Select “SAML-based Sign-on” from the dropdown list under **“Single sign-on” **in your Azure AD business application.

On the SAML page, add the required details in the Domain and URLs section, save and download the SAML File. For context:

• The Identifier has your User Pool id (from AWS), which is constructed using the following pattern: urn:amazon:cognito:sp:us-east-1 XX123xxXXX

• The authentication token should be sent through the Reply URL by the application. In SAML, this is also known as the Assertion Consumer Service (ACS). It follows this pattern: *https://example-setup-app.auth.us-east-1.amazoncognito.com/saml2/idpresponse*

The next thing we are going to do is add “Users”. Invite new users or assign users from a list of existing ones. This will allow the user to access your application using this Azure AD account. To do this, go to “Enterprise apps” -> “Users and groups” -> “Add user”.

Once you’ve finished adding the user, click on “Assign” to save your changes.

Step 4: Set up an identity provider in your AWS User Pool

So far, you now have a SAML file in XML format and a user(s) to log in with. Let’s go ahead and set up an identity provider in your AWS User Pool.

When using a user pool, app users can federate with another identity provider to sign in. To do this, click on “Federation” on the navigation bar -> “Identity Providers” -> “SAML”.

Give your provider a name and upload a SAML file you downloaded from Azure AD, then click on the Create Provider button.

Create a mapping between your provider and AWS attributes. In our case, we’re only interested in the email, so add this *http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress in the SAML Attribute field.*

Now, let’s give our app client an Identity provider. To do this, go to App Integration on the navigation bar -> App Client Settings -> select your application and then click on the Enabled Identity Providers checkbox. Save your changes.

That’s everything you need to accomplish in the AWS management console and Azure site. You may now put your setup to the test.

Step 5: Testing your set-up

In the Azure portal, go to the Single Sign-On area of your application and click on the Test SAML Settings button.

After that, you must install the My Apps Secure Sign-in Extension and sign in using the account that you added to this application in step 3:

If the login succeeds, you’ll be able to view the SAML request and response, as well as the token:

You should now have all the essential data to start setting up SSO authentication with your Azure AD account in your web or mobile application.

Conclusion

To enable your users to sign in to web or mobile apps using their corporate IDs, you learned the SSO process and how to combine an Amazon Cognito user pool with Azure AD as an external SAML identity provider in this blog article.

If you have any questions, you can leave them in the comments section.