Is using HttpOnly cookies to manage AWS Cognito access and refresh tokens a secure and...

We're implementing authentication for multiple SPAs across subdomains of the same parent domain (e.g. app1.mycompany.com, app2.mycompany.com) using AWS Cognito, a custom login UI, and a centralized PHP backend.

We’re not using Cognito Hosted UI — instead, we built our own login screen and want all apps to share authentication via secure cookies.

Here's how my flow works:

• On login, the backend (PHP) uses initiateAuth(USER_PASSWORD_AUTH) to get AccessToken, IdToken, and RefreshToken.
• The tokens are stored as HttpOnly, Secure cookies (not accessible by JavaScript).
• The frontend checks authentication by calling a backend endpoint: /api/session.
• The backend:
• Calls getUser() with AccessToken to verify it's valid
• If the access token is expired, it uses the stored RefreshToken to get a new one (REFRESH_TOKEN_AUTH)
• Then it updates the cookie with a fresh access token and responds with user info

Pros I see:

• Tokens are never exposed to JavaScript → prevents XSS risk
• Refresh is handled silently in the backend → better UX
• Only the backend talks to AWS Cognito → decoupled frontend

My Question:

• 
  Is this considered a secure and scalable approach to authentication with Cognito?
  
  
• 
  Are there any downsides or security issues with this method?
  
  
• 
  Are there better modern alternatives for SPAs using Cognito?
  
  
• 
  What’s the best way for each app to detect session expiration and redirect to login if needed?
  
  
• 
  We currently poll /api/session every X minutes
  
  
• 
  Is there a more elegant or standard way?
  

I'd love to hear thoughts from others who’ve implemented secure SSO or token-based auth flows with Cognito.

Continue reading...