Cognito setup prerequisites
To integrate with Cognito, you need to set up a User Pool and an App client in the Amazon Cognito Console. A User Pool is required for Cognito authentication.
Better Auth · Authentication · all subjects
social sign-on/cognito
9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Cognito console setup steps
In the Cognito Console: (1) Create a User Pool, (2) Under App clients, create a new App client and note the Client ID and Client Secret if enabled, (3) Go to Domain and set a Cognito Hosted UI domain (e.g., your-app.auth.us-east-1.amazoncognito.com), (4) In App client settings, enable Allowed OAuth flows as 'Authorization code grant' and Allowed OAuth scopes as 'openid', 'profile', and 'email', (5) Add your callback URL (e.g., http://localhost:3000/api/auth/callback/cognito). The callback URL must match exactly what you configure in Cognito.
Cognito provider configuration
Configure the cognito key in the socialProviders object with these required parameters: clientId, clientSecret, domain (e.g., 'your-app.auth.us-east-1.amazoncognito.com'), region (e.g., 'us-east-1'), and userPoolId. These should be passed from environment variables.
Cognito sign-in example
To sign in with Cognito, use the signIn.social function from the client: const authClient = createAuthClient() const signIn = async () => { const data = await authClient.signIn.social({ provider: "cognito" }) }
Cognito OAuth scopes available
Available OAuth scopes for Cognito include: openid (required for OpenID Connect authentication), profile (access to basic profile info), email (access to user's email), phone (access to user's phone number), and aws.cognito.signin.user.admin (grants access to Cognito-specific APIs). Default scopes are 'openid', 'profile', and 'email'. You must configure the scopes in your Cognito App Client settings.
Cognito signIn.social options
The signIn.social function accepts these additional options: scope (additional OAuth2 scopes to request, combined with default permissions), getUserInfo (custom function to retrieve user information from the Cognito UserInfo endpoint), and refreshAccessToken (custom function to refresh tokens that receives the stored refresh token).
Cognito refresh token behavior
Cognito returns a refresh token after a successful authorization code grant. Later refresh-token grants return new access and ID tokens. Cognito only returns a new refresh token when refresh token rotation is enabled in the app client; otherwise, the original refresh token remains valid and Better Auth keeps using it.
Cognito access token refresh mechanism
auth.api.getAccessToken refreshes an expired access token automatically when the provider account has a refresh token and a known accessTokenExpiresAt. It returns the valid access token and ID token. If you need the refresh token in the response, use the /refresh-token endpoint instead.
Cognito token storage in database-less setups
In database-less setups, Better Auth stores provider account data including OAuth token material in the encrypted account_data cookie when storeAccountCookie is enabled. Token refresh responses set an updated cookie, so server-side callers must forward the returned Set-Cookie header to the browser. Cognito JWTs can be large; Better Auth chunks oversized account cookies, but browsers and proxies can still enforce total header limits. Use database-backed account storage for large token payloads or production flows that need durable token storage.