JWT & OAuth 2.0 Vocabulary
Learn JWT claims, signing algorithms, OAuth 2.0 grant types, PKCE, and token lifecycle vocabulary.
0 / 22 completed
1 / 22
A JWT (JSON Web Token) consists of three parts:
A JWT is header.payload.signature — each part is Base64URL encoded. The header identifies the algorithm; the payload contains claims; the signature verifies integrity.
2 / 22
The JWT claim 'exp' stands for:
The 'exp' claim is a Unix timestamp representing the expiry time. Tokens should be rejected after this time to prevent replay attacks with stolen tokens.
3 / 22
The OAuth 2.0 Authorization Code flow with PKCE is used for:
PKCE (Proof Key for Code Exchange) solves the public client problem — mobile apps and SPAs cannot store secrets safely, so PKCE uses a code verifier/challenge instead.
4 / 22
OAuth 2.0 Client Credentials grant is appropriate for:
Client Credentials is the M2M OAuth flow — a service uses its client ID and secret to obtain an access token for calling another service, with no user interaction.
5 / 22
A 'refresh token' in OAuth 2.0 is used to:
Refresh tokens are long-lived and used to obtain short-lived access tokens silently — they keep users logged in without requiring repeated credential entry.
6 / 22
Reviewer: 'I noticed you're using a JWT for session management. While functional, consider adding a `jti` (JWT ID) claim to your tokens. This helps with revocation – if we need to invalidate a token quickly, knowing its unique identifier makes it much easier than scanning all active JWTs. Also, ensure proper rotation of the keys used to sign these tokens is implemented. You: 'Oh, I thought the `iss` and `aud` claims covered that.'This question assesses understanding of how JWT ID claims (
jti) enhance security. While `iss` (issuer) and `aud` (audience) claims are vital for token validation, they don't directly facilitate revocation – you'd still need to scan all active JWTs. The jti claim provides a unique identifier that allows rapid invalidation of tokens, which is crucial in many security scenarios; it's a common best practice.7 / 22
Reviewer: 'Hey, I'm seeing you're using the `refresh_token` flow for authentication. That's good for long-lived sessions, but are you also implementing a robust mechanism to invalidate these tokens on user logout or account changes? It's crucial to prevent unauthorized access if a user switches devices or accounts – otherwise, the refresh token could be misused.' You: 'I was relying on the standard refresh token behavior; I hadn't considered explicitly invalidating them.'The reviewer raises a critical point about the security implications of *only* using the standard behavior of refresh tokens. While refresh tokens do expire after inactivity, they don't automatically invalidate upon logout or changes to the user account – this leaves an opening for misuse. Explicit invalidation mechanisms (like blacklisting in a database or revocation lists) are essential for strong security and preventing unauthorized access after a user's session has ended or their credentials have changed. This is a common best practice when dealing with refresh tokens.
8 / 22
PR Description:
"Implemented JWT for user authentication. Using the `sub` claim to identify the user and `exp` for expiration."
During a code review with your team lead, they point out: 'While the JWT is functional, we've been seeing issues where users are experiencing unexpected access after prolonged inactivity. The `exp` claim is set to 24 hours, but some users are still able to authenticate using stale tokens. Could you explore adjusting the expiration time or implementing a mechanism for token revocation?'
Which of the following actions would be MOST appropriate in response?
The correct answer focuses on investigation. Simply shortening the `exp` claim without understanding *why* it's being breached is reactive and may not address the underlying problem. A robust security approach involves identifying the root cause – perhaps session persistence or caching is causing stale tokens to be used. Option B emphasizes proper investigation, which is crucial before making significant changes to your authentication system. Options A and C are overly simplistic and potentially dangerous; option D wouldn't necessarily solve the immediate issue.
9 / 22
Reviewer: 'I noticed you're using a JWT for session management. While functional, consider adding a `jti` (JWT ID) claim to your tokens. This helps with revocation – if we need to invalidate a token quickly, knowing its unique identifier makes it much easier than scanning all active JWTs. Also, ensure proper rotation of the keys used to sign these tokens is implemented. You: 'Oh, I thought the `iss` and `aud` claims covered that.'This question assesses understanding of how JWT ID claims (
jti) enhance security. While `iss` (issuer) and `aud` (audience) claims are vital for token validation, they don't directly facilitate revocation – you'd still need to scan all active JWTs. The jti claim provides a unique identifier that allows rapid invalidation of tokens, which is crucial in many security scenarios; it's a common best practice.10 / 22
Reviewer: 'Hey, I'm seeing you're using the `refresh_token` flow for authentication. That's good for long-lived sessions, but are you also implementing a robust mechanism to invalidate these tokens on user logout or account changes? It's crucial to prevent unauthorized access if a user switches devices or accounts – otherwise, the refresh token could be misused.' You: 'I was relying on the standard refresh token behavior; I hadn't considered explicitly invalidating them.'The reviewer raises a critical point about the security implications of *only* using the standard behavior of refresh tokens. While refresh tokens do expire after inactivity, they don't automatically invalidate upon logout or changes to the user account – this leaves an opening for misuse. Explicit invalidation mechanisms (like blacklisting in a database or revocation lists) are essential for strong security and preventing unauthorized access after a user's session has ended or their credentials have changed. This is a common best practice when dealing with refresh tokens.
11 / 22
PR Description:
"Implemented JWT for user authentication. Using the `sub` claim to identify the user and `exp` for expiration."
During a code review with your team lead, they point out: 'While the JWT is functional, we've been seeing issues where users are experiencing unexpected access after prolonged inactivity. The `exp` claim is set to 24 hours, but some users are still able to authenticate using stale tokens. Could you explore adjusting the expiration time or implementing a mechanism for token revocation?'
Which of the following actions would be MOST appropriate in response?
The correct answer focuses on investigation. Simply shortening the `exp` claim without understanding *why* it's being breached is reactive and may not address the underlying problem. A robust security approach involves identifying the root cause – perhaps session persistence or caching is causing stale tokens to be used. Option B emphasizes proper investigation, which is crucial before making significant changes to your authentication system. Options A and C are overly simplistic and potentially dangerous; option D wouldn't necessarily solve the immediate issue.
12 / 22
Reviewer: 'I noticed you're using a JWT for session management. While functional, consider adding a `jti` (JWT ID) claim to your tokens. This helps with revocation – if we need to invalidate a token quickly, knowing its unique identifier makes it much easier than scanning all active JWTs. Also, ensure proper rotation of the keys used to sign these tokens is implemented. You: 'Oh, I thought the `iss` and `aud` claims covered that.'This question assesses understanding of how JWT ID claims (
jti) enhance security. While `iss` (issuer) and `aud` (audience) claims are vital for token validation, they don't directly facilitate revocation – you'd still need to scan all active JWTs. The jti claim provides a unique identifier that allows rapid invalidation of tokens, which is crucial in many security scenarios; it's a common best practice.13 / 22
Reviewer: 'Hey, I'm seeing you're using the `refresh_token` flow for authentication. That's good for long-lived sessions, but are you also implementing a robust mechanism to invalidate these tokens on user logout or account changes? It's crucial to prevent unauthorized access if a user switches devices or accounts – otherwise, the refresh token could be misused.' You: 'I was relying on the standard refresh token behavior; I hadn't considered explicitly invalidating them.'The reviewer raises a critical point about the security implications of *only* using the standard behavior of refresh tokens. While refresh tokens do expire after inactivity, they don't automatically invalidate upon logout or changes to the user account – this leaves an opening for misuse. Explicit invalidation mechanisms (like blacklisting in a database or revocation lists) are essential for strong security and preventing unauthorized access after a user's session has ended or their credentials have changed. This is a common best practice when dealing with refresh tokens.
14 / 22
PR Description:
"Implemented JWT for user authentication. Using the `sub` claim to identify the user and `exp` for expiration."
During a code review with your team lead, they point out: 'While the JWT is functional, we've been seeing issues where users are experiencing unexpected access after prolonged inactivity. The `exp` claim is set to 24 hours, but some users are still able to authenticate using stale tokens. Could you explore adjusting the expiration time or implementing a mechanism for token revocation?'
Which of the following actions would be MOST appropriate in response?
The correct answer focuses on investigation. Simply shortening the `exp` claim without understanding *why* it's being breached is reactive and may not address the underlying problem. A robust security approach involves identifying the root cause – perhaps session persistence or caching is causing stale tokens to be used. Option B emphasizes proper investigation, which is crucial before making significant changes to your authentication system. Options A and C are overly simplistic and potentially dangerous; option D wouldn't necessarily solve the immediate issue.
15 / 22
Reviewer: 'I noticed you're using a JWT for session management. While functional, consider adding a `jti` (JWT ID) claim to your tokens. This helps with revocation – if we need to invalidate a token quickly, knowing its unique identifier makes it much easier than scanning all active JWTs. Also, ensure proper rotation of the keys used to sign these tokens is implemented. You: 'Oh, I thought the `iss` and `aud` claims covered that.'This question assesses understanding of how JWT ID claims (
jti) enhance security. While `iss` (issuer) and `aud` (audience) claims are vital for token validation, they don't directly facilitate revocation – you'd still need to scan all active JWTs. The jti claim provides a unique identifier that allows rapid invalidation of tokens, which is crucial in many security scenarios; it's a common best practice.16 / 22
Reviewer: 'Hey, I'm seeing you're using the `refresh_token` flow for authentication. That's good for long-lived sessions, but are you also implementing a robust mechanism to invalidate these tokens on user logout or account changes? It's crucial to prevent unauthorized access if a user switches devices or accounts – otherwise, the refresh token could be misused.' You: 'I was relying on the standard refresh token behavior; I hadn't considered explicitly invalidating them.'The reviewer raises a critical point about the security implications of *only* using the standard behavior of refresh tokens. While refresh tokens do expire after inactivity, they don't automatically invalidate upon logout or changes to the user account – this leaves an opening for misuse. Explicit invalidation mechanisms (like blacklisting in a database or revocation lists) are essential for strong security and preventing unauthorized access after a user's session has ended or their credentials have changed. This is a common best practice when dealing with refresh tokens.
17 / 22
PR Description:
"Implemented JWT for user authentication. Using the `sub` claim to identify the user and `exp` for expiration."
During a code review with your team lead, they point out: 'While the JWT is functional, we've been seeing issues where users are experiencing unexpected access after prolonged inactivity. The `exp` claim is set to 24 hours, but some users are still able to authenticate using stale tokens. Could you explore adjusting the expiration time or implementing a mechanism for token revocation?'
Which of the following actions would be MOST appropriate in response?
The correct answer focuses on investigation. Simply shortening the `exp` claim without understanding *why* it's being breached is reactive and may not address the underlying problem. A robust security approach involves identifying the root cause – perhaps session persistence or caching is causing stale tokens to be used. Option B emphasizes proper investigation, which is crucial before making significant changes to your authentication system. Options A and C are overly simplistic and potentially dangerous; option D wouldn't necessarily solve the immediate issue.
18 / 22
In a Slack channel discussing API authentication, Sarah says: 'We're using JWTs for our user sessions. The `aud` claim is set to the API endpoint.' John replies: 'That's good! But are you also including an expiration time (like `exp`) in the JWT? Without it, a compromised token could be used indefinitely.' What does John *primarily* mean?
John is highlighting the importance of the `exp` (expiration) claim in JWTs for security. Without a defined expiration time, a stolen or compromised token could continue to be valid indefinitely, leading to unauthorized access. The 'aud' claim specifies the API endpoint, which is important but doesn't address the issue of token validity over time.
19 / 22
Reviewer comment: 'I noticed you're using a refresh token. It's good that you've implemented this for long-lived sessions, but have you considered setting an expiration time on the refresh token itself? This adds another layer of security against compromised refresh tokens being used indefinitely.' What is the reviewer suggesting?
The reviewer advocates for a layered approach to security by proposing an expiration time on the *refresh token* alongside the access token. This limits the window of opportunity if a refresh token is compromised – it won't be usable forever, and will require the user to re-authenticate.
20 / 22
PR Description:
"Implemented JWT for user authentication. Using the `sub` claim to identify the user and `exp` for expiration."
During a code review with your team lead, they point out: 'The use of `exp` is good practice but are you also logging the JWT ID (jti) somewhere? This would allow us to quickly invalidate tokens if needed.' What does this comment imply about best practices?
The reviewer's comment highlights the value of including the `jti` (JWT ID) claim – this is a unique identifier for each JWT and allows for efficient revocation when necessary, significantly reducing the potential damage from a compromised token. While logging it isn't strictly *mandatory*, it represents a best practice.
21 / 22
"Hey team, I'm working on integrating JWTs for our user authentication flow. We're using the `sub` claim to identify users and setting an expiration time (`exp`) on the tokens. Does anyone have any suggestions or concerns about this approach?"
This question tests understanding of the core value proposition of the `exp` claim – that it prevents stale tokens from being used, which is a fundamental security concern when dealing with JWTs. The other options represent misconceptions about JWT usage or alternative approaches.
22 / 22
You're designing an API that uses JWTs for authentication. A user logs in successfully and receives a JWT with the following claims: `sub` (user ID), `aud` (API endpoint), `exp` (expiration time). Later, you receive an alert indicating a potential security breach – someone might be using a stolen JWT. Which claim would *most* directly help you immediately invalidate that JWT?
The `jti` (JWT ID) is specifically designed to provide a unique identifier for each JWT. Knowing this ID allows you to quickly and efficiently revoke the token, regardless of how it was obtained or where it's being used. While other claims are important, 'jti' provides the most direct mechanism for immediate invalidation.
Frequently Asked Questions
What does the "JWT & OAuth 2.0 Vocabulary" exercise cover?
Learn JWT claims, signing algorithms, OAuth 2.0 grant types, PKCE, and token lifecycle vocabulary.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "JWT & OAuth 2.0 Vocabulary"?
This exercise has 22 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Cryptography & PKI exercises?
Browse the full Cryptography & PKI hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.