パスワードを共有しない
ユーザーはAuthorization Serverだけでログインします。Clientはパスワードではなく、限定されたアクセストークンを受け取ります。
Specification
OAuth 2.0のロール、エンドポイント、Grant Type、アクセストークンの基本モデルを定義する中核仕様です。
Overview
OAuth 2.0は、あるサービスが持つデータや機能を、ユーザーのパスワードを別のアプリへ教えずに利用させるための認可フレームワークです。たとえば写真サービスが持つ写真へ、印刷アプリからアクセスを許可する場面で使われます。
RFC 6749は、Resource Owner、Client、Authorization Server、Resource Serverという4つの役割を分け、Clientがアクセストークンを受け取るまでの基本ルールを定義しました。重要なのは、OAuthが本人確認そのものではなく『どのClientへ、何を、どこまで許可するか』を扱う点です。
Purpose and responsibilities
ユーザーはAuthorization Serverだけでログインします。Clientはパスワードではなく、限定されたアクセストークンを受け取ります。
scopeを使い、プロフィールの参照やデータの更新など、Clientへ許可する操作を必要な範囲に限定します。
ログイン、トークン発行、API提供を別の役割として整理し、それぞれが何を信頼し検証するかを明確にします。
Key concepts
Security considerations
仕様を実装するときは、正常系の通信だけでなく、値のすり替え、再利用、漏えいが起きた場合も考えます。
redirect_uriは事前登録した完全一致URLだけを許可します。
stateで認可リクエストとコールバックを関連付け、CSRFを防ぎます。
アクセストークンは短時間有効にし、TLSで送信します。
Implicit GrantとPassword Grantは現在の新規実装では利用せず、Authorization Code + PKCEを選びます。
Interactive flows
クライアントへパスワードを渡さず、認可コードをアクセストークンへ交換して保護APIへアクセスする基本フローです。
図を再生する →OAuth 2.0 (RFC 6749) · Interactive flowClient Credentials Flowユーザーを介さず、クライアント自身の権限でサービス間APIへアクセスするM2M向けフローです。
図を再生する →OAuth 2.0 (RFC 6749) · Interactive flowRefresh Token Flowアクセストークンの期限切れ後、ユーザーを再認証させずに新しいトークンを取得する継続セッションのフローです。
図を再生する →OAuth 2.0 (RFC 6749) · LegacyImplicit Grant — Legacyアクセストークンをフロントチャネルで直接返す旧方式です。現代のアプリではAuthorization Code + PKCEを使用します。
図を再生する →OAuth 2.0 (RFC 6749) · LegacyResource Owner Password Grant — Legacyクライアントがユーザーのパスワードを直接収集する旧方式です。OAuth 2.1では削除され、新規利用できません。
図を再生する →Position and relationship
RFC 6749がOAuth 2.0の土台です。その後、PKCE、Device Authorization、Token Revocationなどが個別RFCとして追加され、現在の安全な利用方法はOAuth 2.0 Security Best Current PracticeやOAuth 2.1へ整理されています。
Other specifications