OAuthとは：ロール、PKCEフロー、OAuthとSAMLの違い
OAuthの解説
OAuthとは？ロール、PKCEフロー、OAuth・SAML・OIDCの違い | We.Inc
OAuth 2.0をわかりやすく解説します。4つのロール、PKCE付き認可コードフローの各手順、スコープ、そしてOAuthとOpenID Connect、SAMLとの違いを紹介します。
OAuth 2.0は、あるアプリがパスワードを一切見ることなく、別のサービスであなたの代わりに操作できるようにするための標準です。サービス自身のサインインページでリクエストを承認すると、アプリは同意したスコープに限定されたアクセストークンを受け取ります。OAuthが扱うのは認可で、サインインはその上にOpenID Connectが追加します。
OAuth 2.0、OpenID Connect、SAML 2.0の比較
- OAuth 2.0
- OpenID Connect
- SAML 2.0
- 答える問い
- このアプリは何にアクセスできるか
- このユーザーは誰か
- このユーザーは誰か
- 主な成果物
- アクセストークン
- IDトークン（JWT）とアクセストークン
- XMLアサーション
- 仕様
- RFC 6749（IETF）
- OpenID Connect Core 1.0
- OASIS SAML 2.0
- 当事者
- クライアント、認可サーバー、リソースサーバー
- リライングパーティー、OpenIDプロバイダー
- サービスプロバイダー、アイデンティティプロバイダー
- 主な用途
- APIアクセス、「アカウントを連携」
- 「〜でサインイン」ボタン、モバイルやSPAのログイン
- 職場のシングルサインオン
OAuth以前は、2つのサービスを連携させるのに、一方のパスワードをもう一方に入力することがよくありました。OAuthはそれを、承認した後にだけ発行される、有効期間が短く範囲の限られたトークンに置き換えました。下のジェネレーターはブラウザー内で本物のPKCEのverifierとchallengeを作成し、認可URLを組み立てるので、フローで使われる各パラメーターを確認できます。
- アプリはランダムなcode_verifierを作り、それをハッシュしてcode_challengeにし、そのchallenge、自身のclient_id、スコープ、state値を付けてあなたを認可サーバーへ送ります。
- あなたは認可サーバーのページでサインインし、スコープを承認します。
- サーバーは、有効期間の短い認可コードと同じstateを付けて、アプリのredirect_uriへリダイレクトします。
- アプリはstateを確認し、コードと元のcode_verifierをトークンエンドポイントにPOSTします。
- サーバーはverifierをハッシュして保存済みのchallengeと照合し、アプリがAPIに送るアクセストークンを返します。
- シングルページアプリ、モバイルアプリ、サーバーアプリのいずれでも、PKCE付きの認可コードフローを使いましょう。
- stateは必ず送信して確認しましょう。OAuthの仕様では、クロスサイトリクエストフォージェリを防ぐために推奨されています。
- 必要最小限のスコープを要求しましょう。小さな要求のほうが承認されやすくなります。
- リダイレクトURIは正確に登録しましょう。ワイルドカードやオープンリダイレクトは、トークンが盗まれる典型的な原因です。
- クライアントシークレットはサーバーだけに置きましょう。ブラウザーやモバイルアプリはシークレットを守れません。
よくある質問
OAuthは認証ですか、認可ですか？
認可です。アクセストークンが示すのはアプリに何が許されているかであって、ユーザーが誰かではなく、APIがそれを教えてくれるとも限りません。本人の身元が必要な場合は、sub、iss、aud、expなどのクレームを持つ署名付きIDトークンを返すOpenID Connectを使いましょう。
PKCEとは何で、必要ですか？
PKCE（RFC 7636）は、認可コードをフローを開始したアプリに結び付けます。アプリは最初にランダムな秘密値のハッシュを送り、後で秘密値そのものを送るので、盗まれたコードは役に立ちません。plainではなく、サーバーが対応必須とされているS256を使いましょう。
OAuthとSAMLの違いは何ですか？
SAMLはXMLベースの古い標準で、アイデンティティプロバイダーがユーザーに関する署名付きアサーションをサービスプロバイダーに送ります。主にブラウザーでの企業向けシングルサインオンに使われます。OAuthはAPIアクセス用のトークンを発行し、モバイルアプリやAPIとの相性が良好です。OAuthの世界でSAMLのサインインに近いのはOpenID Connectです。
スコープとは何ですか？
スコープはアプリが要求する権限で、認可サーバーが定義する大文字と小文字を区別する文字列を、openid emailやrepo read:userのようにスペース区切りで並べたものです。同意画面に表示され、トークンは承認された範囲だけを対象とします。
インプリシットフローは今でも使うべきですか？
新しく作るものでは使うべきではありません。インプリシットフローはURLのフラグメントでトークンを返すため、履歴やログから漏れるおそれがあります。PKCE付きの認可コードフローなら、その危険なしに、ブラウザーアプリでも同じ手軽さが得られます。
4つのロール
- RFC 6749では、4つの当事者を定めています。リソースオーナーはあなたです。クライアントはアクセスを求めるアプリです。認可サーバーはあなたが誰かを確認してトークンを発行します。リソースサーバーは、そのトークンを受け付けるAPIをホストします。1つの会社が両方のサーバーを運用することも多いですが、役割は別々です。
コード交換がある理由
- アプリへのリダイレクトはブラウザーを経由しますが、ブラウザーは価値のあるものが漏れやすい場所です。そのためリダイレクトには1回限りのコードだけを載せ、仕様ではその有効期限を10分以内にするよう推奨しています。本物のトークンは、トークンエンドポイントへの直接の呼び出しで取得します。
- 残る隙間はPKCEがふさぎます。マルウェアやログを記録するプロキシがコードを捕らえても、アプリから一度も出ていないverifierがなければ引き換えられません。
OpenID Connectの位置付け
- OpenID Connectは、OAuthの上の薄いレイヤーです。OIDCの仕様で必須とされているopenidをスコープに加えると、トークンレスポンスにIDトークン、つまりユーザーを表す署名付きJWTも含まれるようになります。リクエストで送りIDトークンに返されるnonceが、リプレイ攻撃を防ぎます。
PKCE付きの認可コードフロー
各ステップと、そこで受け渡されるパラメーター
- 1. 認可リクエスト
- アプリから認可サーバーへ（ブラウザーのリダイレクト）
- response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256
- 2. サインインと同意
- 認可サーバー上のユーザー
- 認証情報がアプリに渡ることはない
- 3. リダイレクトで戻る
- 認可サーバーからアプリへ
- code, state
- 4. トークンリクエスト
- アプリからトークンエンドポイントへ（直接POST）
- grant_type=authorization_code, code, redirect_uri, client_id, code_verifier
- 5. トークンレスポンス
- トークンエンドポイントからアプリへ
- access_token、token_type、expires_in、任意でrefresh_token（OIDCではid_tokenも）
- 6. API呼び出し
- アプリからリソースサーバーへ
- Authorization: Bearer <access_token>
コードで見るPKCE
ブラウザーでverifierとS256のchallengeを作る
32バイトのランダム値をbase64urlでエンコードすると43文字のverifierになり、これはRFC 7636が認める最短の長さです。
コードをトークンと交換する
リダイレクトの後に実行します。まずstateを比較し、保存しておいたverifierをコードと一緒に送ります。
PKCE・認可URLジェネレーター
ブラウザーの暗号機能で新しいcode_verifierとそのS256のcode_challengeを作成し、設定から認可URLを組み立てます。何も送信されません。下のエンドポイントは置き換えて使うプレースホルダーです。
認可エンドポイント
スコープ（スペース区切り）
新しいverifier
code_verifier（{n}文字、ステップ4まで秘密にする）
code_challenge（S256）
認可URL
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る