OIDC トークン（OIDC Token）

OpenID Connect（OIDC）は OAuth 2.0 の上に「この人は誰か」を伝える認証レイヤーを載せた仕様だ。OAuth 2.0 単体では「このトークンの持ち主にリソースへのアクセスを許可してよい」という認可しか扱えず、ログインしたユーザーが誰なのかをアプリケーション側で知る標準的な手段がなかった。OIDC はその欠落を 3 種類のトークンで埋める。

3 つのトークンの役割

ID トークンが OIDC の中核にあたる。JWT（JSON Web Token）形式で発行され、ペイロードにはユーザー識別子（sub）、発行元（iss）、有効期限（exp）などのクレームが含まれる。署名を検証すれば改ざんの有無を即座に判定でき、IdP（Identity Provider）へ問い合わせる必要がない。この「自己完結した身分証」としての性質が、マイクロサービス間の認証コストを下げる鍵になっている。

アクセストークンは OAuth 2.0 由来で、API やリソースサーバーへのアクセス権を表す。スコープ（openid profile email など）で権限範囲を制限し、有効期限は通常数分〜1 時間程度と短く設定される。

リフレッシュトークンはアクセストークンの有効期限が切れた際に、ユーザーに再ログインを求めずに新しいトークン一式を取得するために使う。長期間有効なぶん漏洩リスクが高く、サーバーサイドでのみ保持し、ローテーション（使用ごとに新しいリフレッシュトークンに差し替え）を有効にするのが実務上の定石だ。

フローの概要

典型的な Authorization Code Flow では、ユーザーが IdP でログインすると認可コードがクライアントに返される。クライアントはこのコードを IdP のトークンエンドポイントに送り、ID トークン・アクセストークン・リフレッシュトークンの 3 点をまとめて受け取る。認可コードは一度しか使えず有効期間も極めて短いため、トークン自体がネットワーク上を流れる回数を最小化できる。

実装上の注意点

筆者が見落としがちだと感じるのはトークンの保管場所だ。SPA（Single Page Application）ではブラウザの localStorage にアクセストークンを保存するパターンが紹介されることがあるが、XSS 攻撃で容易に窃取される。BFF（Backend for Frontend）パターンで HttpOnly Cookie に格納するか、サーバーサイドのセッションストアに保持するほうが安全性は高い。

トークンの有効期限設計にも注意が要る。ID トークンの exp が長すぎると、ユーザーの権限変更やアカウント停止が即座に反映されない。短くしすぎるとリフレッシュ頻度が上がり IdP への負荷が増す。多くの IdP は ID トークン 5〜15 分、アクセストークン 1 時間、リフレッシュトークン 30〜90 日をデフォルトとしており、まずはこの範囲から調整するのが現実的だ。