Why Does AWS Cognito Set an HTTP-Only Cookie Named "cognito" After Google SSO Login?

The "cognito" HTTP-only cookie is part of Cognito's built-in security features and serves a different purpose than storing OAuth tokens:

Cognito Cookie Purpose

• Manages internal session state
• Works with XSRF-TOKEN for CSRF protection
• Not meant for storing OAuth tokens
• Cannot replace custom token management

Your Custom Authorizer Approach is Recommended

• Continue with your planned Lambda Authorizer implementation
• Store OAuth tokens in HTTP-only cookies
• Implement proper CSRF protection
• Handle token refresh securely

Best Practices:

• Keep tokens server-side when possible
• Use secure cookie attributes
• Implement proper session management
• Consider token rotation strategies

For more details:

• Cognito Security Documentation
• OAuth Best Practices

The "cognito" HTTP-only cookie you're observing is part of Amazon Cognito's managed login functionality. This cookie is set by Cognito to preserve successful sign-in attempts for a duration of one hour. It's primarily used for session management and to improve the user experience by allowing users to sign in again within that timeframe without needing to re-enter their credentials.

While this cookie is useful for Cognito's internal session management, it doesn't replace the need for your custom authorizer approach. Your planned flow using a Lambda Authorizer to exchange the authorization code for tokens and set them as HTTP-only cookies is a good security practice. This approach addresses the security concerns of storing tokens in local storage and provides better protection against cross-site scripting (XSS) attacks.

Your proposed flow is a solid approach for secure token handling. Here are some recommendations and considerations:

1. Continue with your plan to use a Lambda Authorizer as an intermediary. This allows you to securely handle the token exchange server-side.

2. When setting the tokens as HTTP-only cookies in your Lambda, make sure to also set the 'Secure' flag to ensure they're only transmitted over HTTPS.

3. Consider implementing CSRF protection. The 'XSRF-TOKEN' cookie you noticed is likely part of Cognito's CSRF protection mechanism. You may want to implement something similar in your custom solution.

4. Be aware that using HTTP-only cookies for tokens will require adjusting how your SPA makes API calls. You'll need to ensure your API Gateway and other backend services are configured to accept and validate these cookies.

5. Implement a mechanism to refresh tokens before they expire. This could be done server-side or by having a secure endpoint that your SPA can call to trigger a refresh.

6. Consider the implications on logout. You'll need to clear these HTTP-only cookies when a user logs out.

Your approach of using a custom authorizer provides you with more control over the authentication flow and token management, which can be beneficial for implementing additional security measures or custom logic. The "cognito" cookie, while useful for Cognito's managed login features, doesn't replace this custom approach, especially if you're looking to implement a more tailored and potentially more secure solution for your specific application needs.
Sources
User pool managed login - Amazon Cognito
Understanding user pool JSON web tokens (JWTs) - Amazon Cognito
Accessing resources after successful sign-in - Amazon Cognito