My name is Sergey Kovalev and I’m a language agnostic engineer with 15+ years of production experience in different domains. I’ve worked with startups, small, medium, big and enterprise companies and have had various roles.
What is SSO and why is it important?
SSO (single sign-on) in the enterprise refers to the ability for employees to log in just one time with one set of credentials to get access to all corporate apps, websites and data for which they have permission. SSO solves key problems for the business by providing:
- Greater security and compliance
- Improved usability and employee satisfaction
- Lower IT costs
The proliferation of cloud apps and services in the enterprise — often in addition to on-prem ones — has created a significant fragmentation problem. Fragmentation in the enterprise is a challenge for IT and users. IT must manage the many apps in the enterprise, as well as deal with shadow IT. Employees have to use more and more apps each day just to complete their work, which means logging in to and switching between multiple apps and websites. SSO helps to solve the enterprise fragmentation problem.
Benefits of SSO
Usernames and passwords are the main target of cybercriminals. Every time a user logs into a new application, it’s an opportunity for hackers. SSO reduced the number of attack surfaces because users only log in once each day and only use one set of credentials.
SSO helps with regulatory compliance
When SSO is a part of an identity and access management (IAM) solution, it utilizes a central directory that controls user access to resources at a more granular level. This allows organizations to comply with regulations that require provisioning users with appropriate permissions. Systems enable SSO with role-based access control (RBAC) and security policies. This type of SSO solution also deprovisions users quickly — or even automatically — another common compliance requirement meant to ensure that former employees, partners, or others can’t access sensitive data.
How SSO improves usability for employees
SSO solutions that are part of an identity and access management system usually have an app portal. To use an app, employees select it from the portal. If the user doesn’t have an app, he or she can request it through the portal and it’s added with SSO enabled. It all happens quickly, so users who might be discouraged from requesting or using apps are more likely to use them.
How SSO lowers IT costs
SSO, which is part of a unified access management system, takes advantage of a central directory to provision and deprovision users, making the process faster and cheaper. Policies can be defined based on user role, location, and other user traits. And employees, partners, and customers can be quickly provisioned across multiple applications in one action, rather than having to separately provision each application. Similarly, IT saves time on deprovisioning, which can be done in minutes instead of hours.
What is Amazon Cognito?
Amazon Cognito lets you easily add user sign-up and authentication to your mobile and web apps. Amazon Cognito also enables you to authenticate users through an external identity provider and provides temporary security credentials to access your app’s backend resources in AWS or any service behind Amazon API Gateway. Amazon Cognito works with external identity providers that support SAML or OpenID Connect, social identity providers (such as Facebook, Twitter, Amazon) and you can also integrate your own identity provider via SAML protocol.
The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your web and mobile app users. Identity pools provide AWS credentials to grant your users access to other AWS services.
A user pool is a user directory in Amazon Cognito. Your app users can sign in either directly through a user pool, or federate through a third-party identity provider (IdP). The user pool manages the overhead of handling the tokens that are returned from social sign-in through Facebook, Google, Amazon, and Apple, and from OpenID Connect (OIDC) and SAML IdPs. Whether your users sign in directly or through a third party, all members of the user pool have a directory profile that you can access through an SDK.
With an identity pool, your users can obtain temporary AWS credentials to access AWS services, such as Amazon S3 and DynamoDB. Identity pools support anonymous guest users, as well as federation through third-party IdPs.
See more info on how to get started with Amazon Cognito here.
Is it possible to customize user sign-up and sign-in workflows?
Yes, you can customize sign-up and sign-in by adding app-specific logic to the user sign-up and sign-in flows using AWS Lambda. For example, you can create AWS Lambda functions to identify fraud or perform additional validations on user data.
You are able to trigger developer-provided Lambda functions at pre-registration, at post-confirmation, at pre-authentication, during authentication to customize the challenges, and at post-authentication. You can also use Lambda functions to customize messages sent as part of email or phone number verification and multi-factor authentication.
Common Cognito Scenarios
Let’s briefly go through common Cognito Scenarios. Here I have listed 6.
-
Authenticate with a User Pool
You can enable your users to authenticate with a user pool. Your app users can sign in either directly through a user pool, or federate through a third-party identity provider (IdP). The user pool manages the overhead of handling the tokens that are returned from social sign-in through Facebook, Google, Amazon, and Apple, and from OpenID Connect (OIDC) and SAML IdPs.
After a successful authentication, your web or mobile app will receive user pool tokens from Amazon Cognito. You can use those tokens to retrieve AWS credentials that allow your app to access other AWS services, or you might choose to use them to control access to your server-side resources, or to the Amazon API Gateway.
2. Access Your Server-side Resources with a User Pool
After a successful user pool sign-in, your web or mobile app will receive user pool tokens from Amazon Cognito. You can use those tokens to control access to your server-side resources. You can also create user pool groups to manage permissions, and to represent different types of users.
Once you configure a domain for your user pool, Amazon Cognito provides a hosted web UI that allows you to add sign-up and sign-in pages to your app. Using this OAuth 2.0 foundation you can create your own resource server to enable your users to access protected resources. If you are interested in more detailed information about any of those scenarios – you can always go to AWS documentation portal.
3. Access Resources with API Gateway and Lambda with a User Pool
You can enable your users to access your API through API Gateway. API Gateway validates the tokens from a successful user pool authentication, and uses them to grant your users access to resources including Lambda functions, or your own API.
You can use groups in a user pool to control permissions with API Gateway by mapping group membership to IAM roles. The groups that a user is a member of are included in the ID token provided by a user pool when your app user signs in.
You can submit your user pool tokens with a request to API Gateway for verification by an Amazon Cognito authorizer Lambda function.
4. Access AWS Services with a User Pool and an Identity Pool
After a successful user pool authentication, your app will receive user pool tokens from Amazon Cognito. You can exchange them for temporary access to other AWS services with an identity pool.
5. Authenticate with a Third Party and Access AWS Services with an Identity Pool
You can enable your users access to AWS services through an identity pool. An identity pool requires an IdP token from a user that’s authenticated by a third-party identity provider (or nothing if it’s an anonymous guest). In exchange, the identity pool grants temporary AWS credentials that you can use to access other AWS services.
6. Access AWS AppSync Resources with Amazon Cognito
You can grant your users access to AWS AppSync resources with tokens from a successful Amazon Cognito authentication (from a user pool or an identity pool).
Let’s go through some real-world examples now.
Let me show you an example of authentication flow for a back office (or admin area if you wish) on top of microservice-based architecture.
This flow is based on the very first scenario we went through (refer to 1. Authenticate with a User Pool). This is where the user pool manages the overhead of handling the tokens that are returned from social sign-in through Facebook, Google, Amazon, and Apple, and from OpenID Connect (OIDC) and SAML IdPs.
This flow is based on our own identity service which is responsible for assigning Roles and permissions for a user based on its identity and issuing our own JWT tokens to perform local authorization without the need to use expensive Amazon API Gateway, where you pay per request.
- On the first step, the user is directed to authenticate through any configured IdP, like MS Azure AD, Salesforce, Facebook, Google and so on and so forth
- User goes from the standard authentication flow in SSO you redirected to (including multi-factor authentication steps)
- SSO IdP comes back with SAML assertion (or using OpenID protocol) and provides user auth details and profile in a specific format. It may seem over-complicated. Believe me or not — SAML protocol is a tough one, hard to understand and implement. But… Cognito does all the heavy-lifting for us for free… with built-in security measures.
- Cognito updates a profile
- Client receives Cognito JWT ID token which can be used later to being authenticated through API Gateway if we would like to
- We go deeper and redirect a client to our own Identity service with a temporary one-time code and state cookie (to eliminate Man-In-The-Middle attacks)
- Having one-time code and secrets for Amazon Cognito, we send a request to Amazon Cognito, get back ID Token, validate it and finally grant access to our microservices based on user roles managed internally on our own
- User gets back JWT Access token stored in for example Secure Cookie
- And on the last step, we can interact with our service while JWT Access and Refresh Token are alive
How to configure Amazon Cognito User Pool
Click on Manage User Pools button and go through the user-friendly setup flow. Let me focus on some important parts of it related to the diagram.
They ask you about the required attributes. In a typical case, we may want to allow only email addresses, enable case insensitivity for username input, and pick only an email address for required or a mandatory attribute for our user in User Pool which will be automatically created or updated during user sign-in procedure.
There you can configure Multi-Factor Authentication (it’s not needed if it’s a part of a flow for your SSO you are integrating with). Settings to recover a password — only if you allow your users to directly sign up through Cognito having their own set of credentials.
Next, you can define Password policy settings if you allow your users to be authenticated directly through Cognito using credentials.
You may set as many as needed App clients for the same cognito instance. It can be a Dev setup with their own set of callback URLs and their own pairs of secrets.
On the screenshot below, you may see that users will be able to use 2 different SSO Identity providers, but not allowed to use User Pool (so, unable to enter credentials directly on Cognito).
Then you can look up secrets, set tokens TTL and enable needed Auth Flows.
In our case, we need to enable SRP (secure remote password) protocol based authentication.
What if you need to add yet another SSO in your typical project? It would lead to a huge amount of work… wouldn’t it?
What about Cognito?
Configuration with ease…
You go to Federated Identity Provider, and configure it by following the step-by-step instructions.
And yes, you can add multiple SAML-based providers.
Let me show you an example of mapping attributes for Google Identity Provider.
Email, name, given name, family name, sub as username… you’ve got it.
Maybe a few hours of work to configure, small or even trivial changes in your application to support yet another SSO and you’re done.
Okay, great! So…
How much does Amazon Cognito cost?
With Amazon Cognito, you pay only for what you use. There are no minimum fees and no upfront commitments.
If you are using the Cognito Identity to create a User Pool, you pay based on your monthly active users (MAUs) only. A user is counted as a MAU if within a calendar month there is an identity operation related to that user, such as sign-up, sign-in, token refresh, and password change. You are not charged for subsequent sessions or for inactive users within that calendar month. Separate charges apply for optional use of SMS messaging if you use them.
The User Pool feature has a free tier of 50,000 MAUs each month. The Cognito Identity free tier does not expire at the end of your 12 month AWS Free Tier term, and it is available to both existing and new AWS customers indefinitely.
Federated Identities and secure access control for AWS resources are always free with Cognito Identity.
If you use SAML or OIDC federation, like we saw in the example of back office authentication flow, the price for MAUs above 50 will be approximately 3 times higher, but still not so big. Let’s calculate it…
1000 MAU who sign in through SAML or OIDC federation:
(1000 – 50) * $0.015 = $14.25 per month
1 000 000 MAU who sign in through SAML or OIDC federation:
(1 000 000 – 50) * $0.015 = $14 999.25 per month
When you propose a solution, you should always do approximate calculations on how much it costs.
For 1000 monthly active users, it would cost approx. $14 per month. For 1M monthly active years, it would cost approx. $15K per month.
What does it mean? It’s cheap if you use Cognito for the back office, or in other words, the admin area. But it could be too expensive for you with a larger number of users.
Finally…
If you are going to use some AWS services and you care about the price, always include approximate calculations in your proposal and think about your use cases. However, AWS Cognito provides configuration with ease and has built-in security features, no maintenance and regular security audits. Is it worth the cost? It’s up to you or your client to decide.
Looking for an AWS solution? Our team of experts can help.
