0Pricing
OAuth2 & OpenID Connect Deep Dive · 课时

令牌安全（访问令牌与刷新令牌）

深入了解安全存储、传输和使访问令牌与刷新令牌过期的最佳实践。

令牌安全（访问令牌与刷新令牌） 是 CoddyKit 上的免费 OAuth2 & OpenID Connect Deep Dive 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 OAuth2 & OpenID Connect Deep Dive 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why Token Security Matters

Welcome to Token Security! In this lesson, we'll dive into protecting the vital components of OAuth2 and OpenID Connect: access tokens and refresh tokens.

These tokens are like digital keys. If they fall into the wrong hands, unauthorized access to your users' data or your application's resources can occur. Securing them is paramount.

Understanding Access Tokens

Access tokens are credentials that grant a client application permission to access specific resources on behalf of the user. Think of them as a temporary pass.

  • They have a short lifespan (minutes to hours).
  • They are used directly to authorize API requests.
  • If compromised, the damage is limited due to their short expiry.

Understanding Refresh Tokens

Refresh tokens are used to obtain new access tokens after the current one expires, without requiring the user to re-authenticate. They are like a master key.

  • They have a much longer lifespan (days, weeks, or even months).
  • They are highly sensitive because their compromise can grant continuous access.
  • They should be stored with the highest level of security.

Secure Transmission: HTTPS/TLS

The most fundamental rule for token security is to always transmit tokens over HTTPS (TLS). This encrypts the communication channel between the client and the server.

Without HTTPS, tokens sent over an unsecured network (like public Wi-Fi) could be easily intercepted by attackers, leading to immediate compromise.

Storing Access Tokens Safely

Access tokens, due to their short lifespan, require careful client-side storage:

  • Web Applications: Store in memory (JavaScript variables) or secure, httpOnly cookies. Avoid localStorage or sessionStorage due to XSS vulnerability.
  • Mobile Applications: Use platform-specific secure storage like iOS Keychain or Android Keystore.

Simulating Token Expiry

Access tokens are designed to expire. This code snippet shows a conceptual way to check if a token, represented by its issue and expiry times, is still valid.

public class Main {
  public static void main(String[] args) {
    long issuedAtMillis = System.currentTimeMillis() - (5 * 60 * 1000); // Token issued 5 minutes ago
    long expiresInMillis = 10 * 60 * 1000; // Token expires in 10 minutes from issue
    long expiresAtMillis = issuedAtMillis + expiresInMillis;

    System.out.println("Token issued 5 minutes ago.");
    System.out.println("Expires 10 minutes from issue.");

    if (System.currentTimeMillis() > expiresAtMillis) {
      System.out.println("Status: Token EXPIRED.");
    } else {
      System.out.println("Status: Token ACTIVE.");
    }
  }
}

Securing Refresh Tokens

Refresh tokens are the most critical to protect due to their long lifespan. Their storage must be even more stringent:

  • Web Applications: Exclusively use httpOnly, secure cookies. Never store in JavaScript-accessible storage.
  • Mobile Applications: Utilize hardware-backed secure storage (e.g., Secure Enclave on iOS, TEE on Android) if available.

Refresh Token Rotation (RTR)

Refresh Token Rotation (RTR) is a crucial security enhancement. Each time a client uses a refresh token to get a new access token, the authorization server should issue a new refresh token and invalidate the old one.

If an old refresh token is stolen and used, the legitimate client will detect it because its current refresh token will no longer work, signaling a potential breach.

Token Revocation Strategies

Tokens should not just expire; they should also be revocable. The authorization server must provide mechanisms to invalidate tokens prematurely.

  • User Logout: All associated access and refresh tokens should be revoked.
  • Password Change: Revoke all active tokens to force re-authentication.
  • Suspicious Activity: If a token is suspected of being compromised, it should be immediately revoked.

Managing Token Lifespans

Balancing security and user experience is key:

  • Access Tokens: Keep their lifespan short (e.g., 5-15 minutes). This limits the window of opportunity for attackers if a token is compromised.
  • Refresh Tokens: Can have longer lifespans (e.g., 7-30 days), but must be revocable and ideally protected with RTR.

Token Security Check

Which of the following are recommended best practices for securing OAuth2/OIDC tokens?

Recap: Secure Tokens

You've learned the critical practices for securing access and refresh tokens!

  • HTTPS/TLS is non-negotiable for transmission.
  • Access tokens need secure, short-lived storage (memory, httpOnly cookies).
  • Refresh tokens demand the highest security (httpOnly, secure cookies, hardware-backed storage) and should use Refresh Token Rotation.
  • Implement effective revocation strategies and manage token lifespans wisely.

常见问题解答

「令牌安全（访问令牌与刷新令牌）」课时是免费的吗？

是的 — 「令牌安全（访问令牌与刷新令牌）」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 OAuth2 & OpenID Connect Deep Dive 课程的其余内容，请升级到 CoddyKit PRO。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

「令牌安全（访问令牌与刷新令牌）」这节课中我会学到什么？

深入了解安全存储、传输和使访问令牌与刷新令牌过期的最佳实践。 你通过在浏览器中直接运行的动手代码来练习 OAuth2 & OpenID Connect Deep Dive，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 OAuth2 & OpenID Connect Deep Dive 需要有经验吗？

无需任何先前经验。CoddyKit 上的 OAuth2 & OpenID Connect Deep Dive 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「令牌安全（访问令牌与刷新令牌）」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 OAuth2 & OpenID Connect Deep Dive 课中编写并运行代码吗？

能。每节 OAuth2 & OpenID Connect Deep Dive 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 令牌安全（访问令牌与刷新令牌）
  2. 状态参数与 CSRF
  3. 授权类型最佳实践
  4. 保护重定向 URI
← 返回 OAuth2 & OpenID Connect Deep Dive