トークンセキュリティ(Access/Refresh)
Access TokenとRefresh Tokenを安全に保存、送信、失効させるためのベストプラクティスを学びます。
「トークンセキュリティ(Access/Refresh)」はCoddyKit上の無料OAuth2 & OpenID Connect Deep Diveレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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
localStorageorsessionStoragedue 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.
よくある質問
「トークンセキュリティ(Access/Refresh)」レッスンは無料ですか?
はい。「トークンセキュリティ(Access/Refresh)」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、OAuth2 & OpenID Connect Deep Diveコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 OAuth2 & OpenID Connect Deep Diveコースには全4レッスンが含まれています。
「トークンセキュリティ(Access/Refresh)」で何を学びますか?
Access TokenとRefresh Tokenを安全に保存、送信、失効させるためのベストプラクティスを学びます。 ブラウザで直接実行するハンズオンコードでOAuth2 & OpenID Connect Deep Diveを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
OAuth2 & OpenID Connect Deep Diveを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのOAuth2 & OpenID Connect Deep Diveは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。
「トークンセキュリティ(Access/Refresh)」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このOAuth2 & OpenID Connect Deep Diveレッスンでコードを書いて実行できますか?
はい。すべてのOAuth2 & OpenID Connect Deep Diveレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- トークンセキュリティ(Access/Refresh)
- StateパラメーターとCSRF
- Grant Typeのベストプラクティス
- リダイレクトURIの保護