Set Up AWS Cognito for Authentication
Users in your AWS Cognito tenant can access applications registered in SecureAuth. In this setup, AWS Cognito acts as an external Identity Provider for SecureAuth, following the Bring Your Own Identity (BYOID) model. Follow these steps to configure the integration.
About Cognito as IDP
Cognito is natively supported by SecureAuth as an OIDC Identity Provider, which means that it has a dedicated connection template in SecureAuth for your convenience. Cognito applications implement the OIDC protocol, providing the proof of user authentication to SecureAuth within an ID Token and Access Token.
The client authorization flow with SecureAuth connected to Cognito looks as follows:
Client app requests the authorization code from SecureAuth.
SecureAuth requests the authorization code from Cognito IDP.
Cognito authenticates the user and asks for consent to share data with SecureAuth.
Cognito issues the code to SecureAuth after user's authentication.
SecureAuth requests tokens from Cognito using the provided code.
Cognito issues the tokens to SecureAuth.
Optionally, SecureAuth uses the token to pull additional user information - only when the Get user info option is selected in the connector. In case of Cognito this shouldn't typically be required, since the user attributes are already exposed in the ID and Access Token.
SecureAuth asks for user consent to share data with the client app, unless the client app is marked as trusted or the requested scopes were already granted for this app.
SecureAuth issues the authorization code to the client app.
Client app requests the tokens from SecureAuth.
SecureAuth issues the tokens to the client app. SecureAuth tokens are minted based on the incoming Cognito tokens with claims mapped to SecureAuth's authentication context.
The following steps in the flow are optional:
SecureAuth only pulls user information if this option is explicitly enabled in the Cognito connector configuration, as explained later in this document.
SecureAuth only asks for consent if the client application is not marked as trusted and requests scopes which were not granted previously (or scopes for which the user's consent has been withdrawn).
Cognito and SAML
Cognito applications can also use the SAML protocol, but this integration is not natively supported by SecureAuth yet. If necessary, you can use the generic SAML connector to bind Cognito apps via SAML.
Prerequisites
AWS account with access to Amazon Cognito console and entitled to manage user pools
Cognito User Pool is created
Client application is registered in Cognito User Pool
Leave out the Callback URL(s) for now. You'll fill it in after getting the URL from the SecureAuth's connector form
In the Enabled Identity Providers section, enable Cognito User Pool.
In the OAuth 2.0 section
For Allowed OAuth Flows, select
authorization code grant
.For Allowed OAuth Scopes, select
email
,profile
, andopenid
.
If you're using custom attributes with your Cognito app, make sure to enable read permissions for them or SecureAuth won't be able to request these attributes. Cognito custom attributes are exposed via the ID token.
Connect Cognito IDP
Basic Configuration
In your workspace, go to Authentication > Providers > Create Connection.
Select the Cognito template and click Next.
Add the redirect URL from SecureAuth as Callback URL in Cognito.
In the Cognito form in SecureAuth, enter the data of the client application integrated with your Cognito user pool.
Parameter
Description
Name
Name for your SecureAuth's Cognito connection. This name allows users to identify the IDP they need to authenticate with.
Pool ID
Pool ID of your Cognito user pool
Region
AWS region where your Cognito user pool is created
Client ID
Client ID of the application registered with Cognito.
Client secret
Secret of the application registered with Cognito
Redirect URL
URL serving as a callback URL for your Cognito client
Optionally, enable Authentication context caching.
Tip
You can enable the authentication context caching if you wish to store the user's authentication context locally. If you do, specify the cache Time To Live as well. Learn more by reading Stateful authorization with SecureAuth.
Select Save.
Result: Your new IDP connection is created. Users can now authenticate via the OIDC-compliant IDP.
Configure Advanced Settings
From the Identities > YOUR_IDENTITY > Configuration page, select Advanced settings at the bottom.
In the Authentication Method Reference, you can select an authentication method to be written into the
amr
object returned by the IDP. Theamr
object is created if it doesn't exist. If it exists, its values are replaced with the selected item.Optionally, enable the Get user info option.
Note
If you enable the Get user info option, the connector calls the Cognito userinfo endpoint to retrieve additional user attributes. In case of Cognito it doesn't typically result in any additional data being returned.
Select Save.
Add custom OIDC IDP attributes
If your IDP returns custom claims outside of the standard OIDC scope, make sure to add them to the IDP connector so that they can be recognized and mapped to the authentication context. Some IDPs (for example Cognito) may require you to set custom attribute permissions first.
Go to Authentication > Providers and select an IDP from the list.
Open the Attributes page. A standard list of OIDC attributes returned by this IDP appears.
Select Add attribute.
In Source, select the data source for the custom attribute
Source
Description
Access token
Get data from the access token received from the IDP
ID token
Get data from the ID token received from the IDP
User info
Get data data returned by the OIDC user info endpoint (note that this must be explicitly enabled on the IDP connector)
Fill in the rest of the form.
Option
Description
Claim name
Name of your custom attribute matching the incoming IDP claim
Display name
User-friendly name for the custom attribute
Data type
Data type matching that of the incoming IDP claim
Claim names with a . character
If the incoming attribute has a
.
character in the name, the dot must be explicitly escaped using\.
when defining the IDP attribute. For example, claim namehttps://example.com/groups
must be entered ashttps://example\.com/groups
.Save your changes and proceed to mapping the attributes to the authentication context.
Map IDP Attributes to Authentication Context
If you've added custom attributes for an IDP, you need to make sure they are mapped to the SecureAuth authentication context. You can do it either from the IDP configuration page (as explained here) or use Data Lineage instead.
Default OIDC/SAML attributes are mapped out of the box.
Go to Authentication > Providers and select an IDP from the list.
Open the Mappings page. A standard attribute mapping for this IDP appears.
Select Add mapping and map any custom IDP attributes to an existing authentication context attribute.
Note
If you need to create new authentication context attributes, read the Managing Authentication Context.
Optionally, you can enrich authentication context before issuing the token to the client. Attributes returned by the script do not need to be separately mapped to the authentication context.
Save your changes. Your mapped custom attributes should now be shared in the ID token issued to your client application, given that the target application requests them (you can check this in Data Lineage).
Connect Extensions to your IDP
Go to Authentication > Providers > YOUR_IDP > Extensions.
Assign a Post Authentication script to the IDP. This script will be executed upon user authentication via this IDP.
Connect your application to the IDP in the Post Authentication application field. Users will be redirected to this application upon authentication via this IDP.
Note
Post Authentication applications must be explicitly enabled in your tenant using the
custom_apps
feature flag.
Test Cognito IDP
Prerequisite
Your provider is configured as a user-authentication method by your administrator.
Workspace is available.
Test
Open the user portal.
Select LOGIN TO DEMO APP.
Select your configured IDP and, next, authenticate in IDP.
Result: SecureAuth displays the consent page that lists data scopes to be shared with the application. When you proceed to the application (ALLOW ACCESS), the PII data coming from IDP is delivered through the access token and the ID token generated by SecureAuth.
Note
For information on granting and managing SecureAuth consents, see Consents.