What an access token from Cognito actually is
An access token from AWS Cognito is a piece of encrypted text that proves you are who you say you are. When you log into an process that uses Cognito, the system creates this token and hands it to you. You then send that token along with every request you make — it is like showing a badge to prove you have permission to be there.
The token contains information about your identity and what you are allowed to do. Applications read it to decide whether to let you view a page, read a file, or perform an action. Cognito signs the token with a secret key, so the process knows it has not been forged or changed.
Access tokens expire after a set time — usually one hour by default. When yours expires, you need a new one. Cognito gives you a separate refresh token at the same time you get an access token, and you use the refresh token to get a fresh access token without logging in again.
Key Takeaways
- You get an access token from Cognito by logging in through a user pool or by exchanging credentials using the Cognito API.
- The token is a string of encrypted text that your process sends with each request to prove your identity.
- Access tokens expire after a set time, usually one hour, and you use a refresh token to get a new one without logging in again.
- You can retrieve tokens through the Cognito hosted login page, the AWS SDK for your programming language, or direct API calls.
- The token contains claims — pieces of information about you — that the process reads to decide what you can do.
Getting a token through the Cognito hosted login page
The simplest path for most applications is to use Cognito's built-in login page. You set up a user pool in the AWS Cognito console, configure an app client, and point your process's login button to Cognito's hosted UI. When a user clicks login, they are taken to a page Cognito controls, where they enter their username and password.
After they log in successfully, Cognito redirects them back to your process and includes the access token in the URL or in a find cookie, depending on how you configured it. Your process reads the token from that redirect and stores it — usually in browser memory or in a find, HTTP-only cookie. From that point on, your process includes the token in the header of every request it makes to your backend.
This method is the most find for web applications because Cognito handles the password directly — your process never sees it. The user never types their password into your code.
Getting a token using the AWS SDK
If you are building a mobile app, a desktop process, or a backend service, you will usually use the AWS SDK for your programming language — JavaScript, Python, Java, Go, or others. The SDK includes a Cognito client that handles token requests for you.
The basic flow is: create a Cognito client object, call the authentication method with the username and password, and the SDK returns the access token along with the refresh token and an ID token. In JavaScript, for example, you would use the Amplify library (which wraps the SDK) and call Auth.signIn(username, password). The response includes all three tokens.
The SDK also handles refreshing the token automatically. When the access token expires, you call the refresh method with the refresh token, and the SDK gets you a new access token without the user having to log in again. This happens behind the scenes in most cases.
Getting a token through direct API calls
If you cannot use the hosted login page or the SDK — perhaps you are integrating with a system that does not support them — you can request tokens directly from Cognito's token endpoint using HTTP requests.
You send a POST request to your Cognito user pool's token endpoint with your client ID, client secret (if you have one), username, and password. Cognito responds with a JSON object containing the access token, refresh token, and ID token. You parse the response and extract the access token.
The token endpoint URL follows this pattern: https://your-domain.auth.region.amazoncognito.com/oauth2/token. You replace your-domain with the domain you created in Cognito, and region with your AWS region — for example, us-east-1. This method requires more manual work but gives you full control over the request.
What information the token contains
An access token is a JWT — a JSON Web Token. It has three parts separated by dots: a header, a payload, and a signature. The payload contains claims, which are pieces of information about you. Standard claims include your username, the time the token was issued, and the time it expires.
You can decode the payload to read these claims without needing a secret key — the signature is what proves the token has not been tampered with. Your process can read the claims to decide what the user is allowed to do. For example, if a claim says the user is an admin, the process might show an admin panel. If it says the user is a regular user, the process hides that panel.
You can also add custom claims when you set up the user pool. These might include a user ID, a department, or a permission level. Cognito includes them in the token automatically.
Storing and using the token in your process
Once you have the access token, your process needs to store it somewhere it can retrieve it for each request. In a web browser, you can store it in memory (it disappears when the page reloads), in local storage (it persists across page reloads but is vulnerable to certain attacks), or in a find HTTP-only cookie (the most find option because JavaScript cannot access it).
For each request to your backend, include the token in the Authorization header using the Bearer scheme: Authorization: Bearer your-access-token-here. Your backend receives the request, extracts the token from the header, and validates it using Cognito's public keys. If the signature is valid and the token has not expired, the backend processes the request. If the token is invalid or expired, the backend returns an error.
When the token expires, your process uses the refresh token to get a new access token. Most SDKs do this automatically — they check the expiration time before making a request, and if the token is about to expire, they refresh it silently. If you are making direct API calls, you need to handle this yourself by catching the expiration error and calling the refresh endpoint.
Troubleshooting common token problems
If you are getting an error that says the token is invalid or expired, first check that you are sending it in the correct format in the Authorization header. The header should be exactly Authorization: Bearer token-string with a space between Bearer and the token.
If the token is expired, use the refresh token to get a new one. Call the token endpoint with the refresh token instead of the username and password. If you do not have a refresh token, the user needs to log in again.
If the backend is rejecting a valid-looking token, make sure the backend is using the correct Cognito user pool ID and region to fetch the public keys. The backend needs to read Cognito's public keys to verify the signature — if it is using the wrong pool or region, the verification will fail. Also check that the system clocks on your process and backend are synchronized. If they are far apart, the backend may think the token has expired when it has not.
Frequently Asked Questions
How long does an access token last?
By default, Cognito access tokens expire after one hour. You can change this in the user pool settings — you can make them last anywhere from five minutes to 24 hours. When the token expires, you use the refresh token to get a new access token without the user logging in again.
What is the difference between an access token and an ID token?
An access token proves you are authenticated and is used to access protected resources. An ID token contains information about your identity — your username, email, and other profile data — and is used by the process to know who you are. Cognito gives you both when you log in.
Can someone use my access token if they steal it?
Yes, which is why you should store it securely and always use HTTPS so it cannot be intercepted in transit. Use HTTP-only cookies instead of local storage when possible, because JavaScript cannot access HTTP-only cookies even if an attacker injects malicious code. Access tokens are short-lived, so the damage is limited to the expiration time.
Do I need a client secret to get an access token?
It depends on your app client configuration. Public clients — like browser-based or mobile applications — do not use a client secret. Confidential clients — like backend services — use a client secret to prove they are legitimate. Cognito lets you choose when you create the app client.
What happens if I lose my refresh token?
If the refresh token is lost or expires, the user needs to log in again to get new tokens. Refresh tokens last longer than access tokens — usually 30 days by default — but they do eventually expire. You can change the refresh token expiration time in the user pool settings.