This page describes security best practices that you can implement when you want to guard against common threats. The configuration that you choose will depend on the use case of each application. We recommend that at a minimum, you apply least privilege to administrative operations and take action to guard application and user secrets. Another advanced but effective step that you can take is to configure and apply AWS WAF web ACLs to your user pools.
Protect your user pool at the network levelAWS WAF web ACLs can protect the performance and cost of the authentication mechanisms that you build with Amazon Cognito. With web ACLs, you can implement guardrails in front of API and managed login requests. Web ACLs create network- and application-layer filters that can drop traffic or require a CAPTCHA based on rules that you devise. Requests arenât passed to your Amazon Cognito resources until they meet the qualifications in your web ACL rules. For more information, see AWS WAF web ACLs.
Protect against SMS message abuseWhen you permit public sign-up in your user pool, you can configure account verification with codes that Amazon Cognito sends in SMS text messages. SMS messages can be associated with unwanted activity and increase your AWS bill. Configure your infrastructure to be resilient against sending SMS messages under circumstances of fraud. For more information, review the following posts from AWS Blogs.
Understand public authenticationAmazon Cognito user pools have customer identity and access management (CIAM) features that support use cases where members of the general public can sign up for a user account and access your applications. When a user pool permits self-service sign-up, itâs open to requests for user accounts from the public internet. Self-service requests come in from API operations like SignUp and InitiateAuth, and from user interaction with managed login. You can configure user pools to mitigate abuse that might come in from public requests, or disable public authentication operations entirely.
The following settings are some of the ways that you can manage public and internal authentication requests in your user pools and app clients.
Examples of user pool settings that affect public user pool access Setting Available options Configured on Effect on public authentication Console setting API operation and parameter Self-service sign-up Permit users to sign up for an account or create user accounts as an administrator. User pool Prevent public sign-up Sign-up â Self-service sign-upCreateUserPool, UpdateUserPool
AdminCreateUserConfig â AllowAdminCreateUserOnly
CreateUserPool, UpdateUserPool
AccountRecoverySettings â admin_only
CreateUserPoolClient, UpdateUserPoolClient
PreventUserExistenceErrors
GenerateSecret
ResourceArn
CreateUserPoolClient, UpdateUserPoolClient
SupportedIdentityProviders
Creation of any user pool domain makes public webpages available.
Threat protection Enable or disable monitoring for signs of malicious activity or unsafe passwords User pool or app client Can automatically block sign-in or require MFA when users show indicators of compromise Threat protection â Protection settingsThe parameters of SetRiskConfiguration define your threat protection settings.
The client secret is an optional string thatâs associated with an app client. All authentication requests to app clients with client secrets must include a secret hash thatâs generated from the username, client ID, and client secret. Those who donât know the client secret are shut out of your application from the beginning.
However, client secrets have limitations. If you embed a client secret in public client software, your client secret is open to inspection. This opens the ability to create users, submit password-reset requests, and perform other operations in your app client. Client secrets must be implemented only when an application is the only entity that has access to the secret. Typically, this is possible in server-side confidential client applications. This is also true of M2M applications, where a client secret is required. Store the client secret in encrypted local storage or AWS Secrets Manager. Never let your client secret be visible on the public internet.
Protect other secretsYou authentication system with Amazon Cognito user pools might handle private data, passwords, and AWS credentials. The following are some best practices for handling secrets that your application might access.
Users might enter passwords when they sign in to your application. Amazon Cognito has refresh tokens that your application can employ to continue expired user sessions without a new password prompt. Donât place any passwords or password hashes in local storage. Design your application to treat passwords as opaque and only pass them through to your user pool.
As a best practice, implement passwordless authentication with WebAuthn passkeys. If you must implement passwords, use the Secure Remote Password (SRP) authentication flow and multi-factor authentication (MFA).
Administrative authentication and user pool administrative operations require authentication with AWS credentials. To implement these operations in an application, grant secure access to temporary AWS credentials. Grant credentials access only to applications that run on a server component that you control. Donât put applications that have AWS credentials in them on public version-control systems like GitHub. Donât encode AWS credentials in public client-side applications.
Proof Key for Code Exchange, or PKCE, is for OpenID Connect (OIDC) authorization-code grants with your user pool authorization server. Applications share code verifier secrets with your user pool when they request authorization codes. To exchange authorization codes for tokens, clients must reaffirm that they know the code verifier. This practice guards against issuing tokens with intercepted authorization codes.
Clients must generate a new random code verifier with each authorization request. The use of a static or predictable code verifier means that an attacker is only then required to intercept the hardcoded verifier and the authorization code. Design your application so that it doesnât expose code verifier values to users.
IAM policies can define the level of access that principals have to Amazon Cognito user pool administration and administrative authentication operations. For example:
To a webserver, grant permissions for authentication with administrative API operations.
To an AWS IAM Identity Center user who manages a user pool in your AWS account, grant permissions for user pool maintenance and reporting.
The level of resource granularity in Amazon Cognito is limited to two resource types for IAM policy purposes: user pool and identity pool. Note that you canât apply permissions to manage individual app clients. Configure user pools with the knowledge that permissions that you grant are effective across all app clients. When your organization has multiple application tenants and your security model requires separation of administrative responsibilities between tenants, implement multi-tenancy with one tenant per user pool.
Although you can create IAM policies with permissions for user authentication operations like InitiateAuth, those permissions have no effect. Public and token-authorized API operations arenât subject to IAM permissions. Of the available user pool authentication operations, you can only grant permissions to administrative server-side operations like AdminInitiateAuth.
You can limit levels of user pool administration with least-privilege Action lists. The following example policy is for an administrator who can manage IdPs, resource servers, app clients, and the user pool domain, but not users or the user pool.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserPoolClientAdministrator",
"Action": [
"cognito-idp:CreateIdentityProvider",
"cognito-idp:CreateManagedLoginBranding",
"cognito-idp:CreateResourceServer",
"cognito-idp:CreateUserPoolDomain",
"cognito-idp:DeleteIdentityProvider",
"cognito-idp:DeleteResourceServer",
"cognito-idp:DeleteUserPoolDomain",
"cognito-idp:DescribeIdentityProvider",
"cognito-idp:DescribeManagedLoginBranding",
"cognito-idp:DescribeManagedLoginBrandingByClient",
"cognito-idp:DescribeResourceServer",
"cognito-idp:DescribeUserPool",
"cognito-idp:DescribeUserPoolClient",
"cognito-idp:DescribeUserPoolDomain",
"cognito-idp:GetIdentityProviderByIdentifier",
"cognito-idp:GetUICustomization",
"cognito-idp:ListIdentityProviders",
"cognito-idp:ListResourceServers",
"cognito-idp:ListUserPoolClients",
"cognito-idp:ListUserPools",
"cognito-idp:SetUICustomization",
"cognito-idp:UpdateIdentityProvider",
"cognito-idp:UpdateManagedLoginBranding",
"cognito-idp:UpdateResourceServer",
"cognito-idp:UpdateUserPoolClient",
"cognito-idp:UpdateUserPoolDomain"
],
"Effect": "Allow",
"Resource": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_EXAMPLE"
}
]
}
The following example policy grants user and group management and authentication to a server-side application.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserAdminAuthN",
"Action": [
"cognito-idp:AdminAddUserToGroup",
"cognito-idp:AdminConfirmSignUp",
"cognito-idp:AdminCreateUser",
"cognito-idp:AdminDeleteUser",
"cognito-idp:AdminDeleteUserAttributes",
"cognito-idp:AdminDisableProviderForUser",
"cognito-idp:AdminDisableUser",
"cognito-idp:AdminEnableUser",
"cognito-idp:AdminForgetDevice",
"cognito-idp:AdminGetDevice",
"cognito-idp:AdminGetUser",
"cognito-idp:AdminInitiateAuth",
"cognito-idp:AdminLinkProviderForUser",
"cognito-idp:AdminListDevices",
"cognito-idp:AdminListGroupsForUser",
"cognito-idp:AdminListUserAuthEvents",
"cognito-idp:AdminRemoveUserFromGroup",
"cognito-idp:AdminResetUserPassword",
"cognito-idp:AdminRespondToAuthChallenge",
"cognito-idp:AdminSetUserMFAPreference",
"cognito-idp:AdminSetUserPassword",
"cognito-idp:AdminSetUserSettings",
"cognito-idp:AdminUpdateAuthEventFeedback",
"cognito-idp:AdminUpdateDeviceStatus",
"cognito-idp:AdminUpdateUserAttributes",
"cognito-idp:AdminUserGlobalSignOut",
"cognito-idp:AssociateSoftwareToken",
"cognito-idp:ListGroups",
"cognito-idp:ListUsers",
"cognito-idp:ListUsersInGroup",
"cognito-idp:RevokeToken",
"cognito-idp:UpdateGroup",
"cognito-idp:VerifySoftwareToken"
],
"Effect": "Allow",
"Resource": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_EXAMPLE"
}
]
}
Tokens can contain internal references to group membership and user attributes that you might not want to disclose to the end user. Donât store ID and access tokens in local storage. Refresh tokens are encrypted with a key that only your user pool can access, and are opaque to users and applications. Revoke refresh tokens when users sign out or when you determine that persisting a users' session is undesired for security reasons.
Use access tokens to authorize access only to systems that independently verify that the token is valid and unexpired. For verification resources, see Verifying a JSON web token.
Determine the identity providers that you want to trustWhen you configure your user pool with SAML or OIDC identity providers (IdPs), your IdPs can create new users, set user attributes, and access your application resources. SAML and OIDC providers are typically used in business-to-business (B2B) or enterprise scenarios where you or your immediate customer controls membership and configuration of the provider.
Social providers offer user accounts to anyone on the internet and are less under your control than enterprise providers. Only activate social IdPs in your app client when youâre ready to allow public customers to sign in and access resources in your application.
Understand the effect of scopes on access to user profilesYou can request access-control scopes in your authentication requests to the user pool authorization server. These scopes can grant your users access to external resources, and they can grant users access to view and modify their own user profiles. Configure your app clients to support the minimum scopes necessary for the operation of your application.
The aws.cognito.signin.user.admin scope is present in all access tokens issued by SDK authentication with operations like InitiateAuth. Itâs designated for user profile self-service operations in your application. You can also request this scope from your authorization server. This scope is required for token-authorized operations like UpdateUserAttributes and GetUser. The effect of these operations is limited by the read and write permissions of your app client.
The openid, profile, email, and phone scopes authorize requests to the userInfo endpoint on your user pool authorization server. They define the attributes that the endpoint can return. The openid scope, when requested without other scopes, returns all available attributes, but when you request more scopes in the request, the response is narrowed down to the attributes represented by the additional scopes. The openid scope also indicates a request for an ID token; when you omit this scope from your request to your Authorize endpoint, Amazon Cognito only issues an access token and, when applicable, a refresh token. For more information, see OpenID Connect scopes at App client terms.
User attributes that might end up as delivery methods and usernames, for example email, have format restrictions. Other attributes can have string, boolean, or number data types. String attribute values support a variety of inputs. Configure your application to guard against attempts to write unwanted data to your user directory or the messages that Amazon Cognito delivers to users. Perform client-side validation of user-submitted string attribute values in your application before submitting them to Amazon Cognito.
User pools map attributes from IdPs to your user pool based on an attribute mapping that you specify. Only map secure and predictable IdP attributes to user pool string attributes.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4