User pools, identity pools, and JWTs
1. User pools, identity pools, and JWTs
Welcome back! Chapter one settled which identity AWS checks and what a policy lets it do. Now we move up a layer: to the people using your application. They sign up, sign in, and they're not AWS principals.2. Cognito is two services in one name
AWS handles them with Amazon Cognito. You could build sign-in yourself, but password storage, reset flows, and multi-factor are security-critical code you would own forever. Cognito runs that for you. Under one name it is two services, answering two questions.3. Cognito is two services in one name
Do you need to sign users in? That's the user pool. Do you need AWS credentials for them? That's the identity pool. Most real applications need both, so let's look at each in detail.4. A user pool signs users in
A user pool is a user directory that Cognito runs for you, handling sign-up, sign-in, password resets, and multi-factor authentication.5. A user pool signs users in
When a sign-in succeeds, the pool returns three tokens.6. A user pool signs users in
An ID token saying who the user is, an access token saying what they may call, and a refresh token to get fresh ones later.7. An identity pool issues AWS credentials
But none of those tokens can open a storage bucket. They are proof for your application, not for AWS. An identity pool covers that gap: it takes a token from an identity you trust and returns temporary AWS credentials.8. An identity pool issues AWS credentials
You have seen this trade before. In chapter one, a build job presented an outside token and got the same expiring credentials. The identity pool is the desk that takes proof you already have and hands back a hotel keycard.9. One app, both parts
Here's one application using both. The browser signs in and sends a token with every API call. That is a bearer token: whoever holds it can use it, like a cinema ticket with no name. Your API verifies it before answering.10. One app, both parts
That token is then traded to get credentials when the browser reaches another service.11. One app, both parts
For instance, it might reach S3, or another service, with the credentials the identity pool returned. Tokens go to your code. Credentials go to AWS.12. A token is text with a signature
Your API received a token. A JWT, or JSON Web Token, is three chunks of encoded text joined by dots. A header, then a payload of claims, meaning labeled statements about the user, then a signature.13. A token is text with a signature
A JWT is encoded, not encrypted, so it travels like a postcard: anyone in the chain can read it, and anyone can rewrite it. The signature is the only seal on it.14. Verify before you read
So verification comes first, before you read a single claim. Cognito publishes its signing keys at a JWKS endpoint, a JSON Web Key Set, a public list anyone can fetch. Check the signature against those keys.15. Verify before you read
A valid signature proves nobody edited the token. Three claims prove it belongs here. Issuer says it came from your pool, not another. Audience says it was for your app. Expiry says it has not run out.16. A verified token can still be wrong
One more check, and it's the one people miss. A token can pass all four tests and still be the wrong kind. An ID token is a passport, an access token a boarding pass. Neither does the other's job.17. A verified token can still be wrong
The token_use claim says which kind you're holding. An access token carries scopes and is what authorizes an API call. The sub claim names which user, and unlike an email it never changes. Check token_use, or you'll accept identity as permission.18. Let's practice!
Let's put token verification into practice with a few exercises.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.