As our world continues to progress into the digital age, we find ourselves increasingly spending more and more time doing things online. Given the global nature of the internet, unlike our physical offices and retail storefronts, proving a user’s identity in the digital landscape is difficult to do with physical identifiers, like government-issued IDs, creating a unique problem for developers. Coupling this with the daily news of hacked user databases, authenticating your users can feel like a nightmare. Luckily, for internet services that are hosted on Amazon Web Services (AWS), Amazon has come to the rescue with its authentication service: Cognito.

Utilizing Cognito for User Authentication

What is Cognito?

Among the litany of services that are offered under the AWS umbrella, Cognito is a tool designed to allow for authenticating external users of a hosted app. Unlike IAM (Identity and Access Management, Amazon's web service where you can control and manage user access), Cognito is specifically designed for giving (or preventing) access to a hosted application and not the AWS console itself. Being a native AWS service, Cognito enjoys the benefits of being easy to set up and integrate into any AWS-hosted application, as well as being quite affordable for even a moderate number of users.

What are the native functions of Cognito?

Like many other AWS services, Cognito comes bundled with a variety of native functions that can make it suitable for handling the entirety of backend authentication for many apps. By default, Cognito allows administrators to add users directly via the management console, through an import on the management console, or dynamically via a client-facing self-service registration that can be integrated directly into your hosted application. In the same fashion, the management of users can be handled by the same means, including assigning users to specific groups, roles, and permissions.

To this end, Cognito is a powerful tool that allows administrators to have a variety of means for creating and managing every aspect of user accounts from usernames, email addresses, and email verification, to permissions across individual users and user groups.

An important thing to note: as an added level of security, Cognito does not allow administrators to view or import user passwords or hashes. Passwords can only be set or reset to a temporary password to ensure the only person who has access to a user’s password is the user themselves.

Using Third Parties to Authenticate with Cognito

Native Third-Party Authorizers

While natively handling users in Cognito is adequate for a variety of applications, many modern systems opt for allowing users to register and authenticate themselves via a third party. One of the major reasons for this design choice can be a simplification of the registration process to reduce the time external users spend creating an account. In this situation, developers will often be looking for ways to integrate with popular services that already have large user bases. Luckily, Amazon has recognized this need and has laid the foundation for some of the most popular services. Natively, Amazon has designed integrations with Cognito and the following identity providers.

Facebook
Google
Amazon
Apple

cognito native identity provider selection.

Each of these integrations requires registering your app with their service, a process that varies between providers. Once the registration is complete, connecting Cognito to the third party is quite simple and just requires entering the App ID supplied by the provider and mapping the fields returned from the service to Cognito’s internal fields.

cognito native identity provider configuration.

Options for Custom Third-Party Authentication

For developers looking to use Cognito with a third-party service not natively handled, fear not! Amazon has also made provisions to utilize Cognito with both SAML and OpenID services. Both methods are mature, time-tested, and secure ways of authenticating, but they vary in scope, use case, and difficulty in implementation.

OpenID Connect (OIDC)

Beginning with the newer and easier to implement option: OpenID Connect. OIDC is a framework built on the OAuth 2.0 protocol that utilizes an additional JSON Web Token (JWT) to handle scope. Since it follows a very standardized protocol, it's quite easy to verify identity across a variety of use cases, including web applications and, notably, cell phone applications.

With Cognito specifically, setting up the integration can be especially easy, as much of the backend process is handled automatically. Configuration can be as simple as entering the Client ID and Client Secret provided by the authenticating party, setting the attribute request method, and entering the OIDC request endpoint in the Issuer URL section.

For added customization, Cognito also offers a section to add identifier domains to redirect groups of users based on the domain of their email, a very helpful feature for apps with user bases that may need to authenticate to different identity providers (IdPs). If necessary, the retrieval endpoints can also be manually configured by selecting the manual input option and manually setting each endpoint for your specific identity provider.

cognito authentication openid configuration figure 1.

cognito authentication openid configuration figure 2.

Security Assertion Markup Language (SAML)

In addition to OIDC, Cognito also has a framework in place to utilize Security Assertion Markup Language (SAML) as a method for authenticating users. SAML utilizes a custom XML framework to handle transferring authentication information and is generally only used for authenticating to websites. At a glance, the higher difficulty in configuration and more narrow scope of use may make SAML appear to be an antiquated technology. However, it is precisely this reliance on XML that gives SAML a strong argument for use in enterprise applications.

Due to the increased granularity of control at a central endpoint, SAML is often used to handle authorization in addition to authentication, allowing administrators to control not only who can access resources, but also what resources they can access. In a multi-application environment like a company intranet, handling all of this from a central point prevents administrators from needing to configure access in each individual app for each user or group of users.

Configuring a SAML authentication service in Cognito is, on the surface, quite simple. Examining the configuration page, we see that, aside from mapping SAML attributes to Cognito information fields, it only requires administrators to upload an XML-formatted SAML metadata document (or an endpoint where this document can be obtained). The difficult aspect of the process resides in the creation of this metadata document, a task that can vary wildly in complexity depending on the identity provider. Some IdPs like Auth0 have tools to create these documents automatically, which can be an attractive quality to some when selecting an identity provider source.

Regardless of how it is generated, due to the highly variable nature of these documents, you’ll want to consult your IdPs documentation when creating a SAML metadata document to ensure it is formatted properly.

cognito authentication saml configuration.

Conclusion

As security becomes a greater concern in the digital landscape, the means of authenticating users will remain an important consideration when developing any application. If you have questions about authenticating users in your web application or are looking for help keeping your application safe with Amazon’s Cognito service, contact DB Services and we can help you create an affordable and scalable solution for your business.