【仕組み解説】OAuthはどうやってアクセスを許可するのか — 認可コード・PKCE・ログインとの違いを図解

ひよこ

予定管理アプリにカレンダーを連携するとき、カレンダーのパスワードも渡すの？

ペンギン先生

ここで説明するOAuth 2.0の認可コードフローでは、連携先アプリにパスワードを渡さず、必要な操作を許可できるよ。たとえば「予定を読むことは許可するけれど、書き換えは許可しない」というイメージだね。部屋の合鍵より、使える場所が決まった入館証に近いんだ。

ひよこ

「誰かを確かめる」と「許可する」は違うんだね。誰がその許可を出すの？

ペンギン先生

認証は本人を確かめること、認可は操作を許すことだよ。登場するのは利用者、連携するアプリ、許可を扱う認可サーバー、予定などを提供するAPIの4つ。最後のAPI側をリソースサーバーと呼ぶんだ。認可サーバーとAPIが同じサービス内にある場合もあるよ。

ひよこ

連携ボタンを押すと、何が起きるの？

ペンギン先生

アプリが求める権限の範囲、つまりスコープを指定し、ブラウザを認可サーバーへ案内するよ。必要なログインや同意の確認が済むと、登録された戻り先へ短時間だけ使える認可コードが届く。続いてアプリがコードをトークン交換用の窓口へ送り、アクセストークンを受け取るんだ。それを使ってAPIに予定の読み取りを頼むよ。

ひよこ

コードを途中で拾った人も、トークンに交換できそうだけど…？

ペンギン先生

その横取りへの対策の一つがPKCE（ピクシー）だよ。アプリは連携を始めるたびに予測しにくいcode_verifierを作り、S256方式で変換したcode_challengeを先に送る。交換時には元のverifierを示して照合するんだ。コードだけを盗んでも、この照合を通れないようにする仕組みだね。通信やアプリ自体の保護も必要だよ。

ひよこ

クライアントシークレットという合言葉も必要なの？

ペンギン先生

安全に秘密を保管できるサーバー型のアプリでは、シークレットなどでアプリ自身を認証するよ。一方、配布するスマホアプリやブラウザ内のアプリに共通の秘密を埋め込んでも、秘密として守れない。こうした公開クライアントでは認可コードフローにPKCEが必須とされ、サーバー型にも推奨されているんだ。PKCEはアプリ全体の身元を証明するシークレットの代用品ではないよ。

ひよこ

じゃあ「ほかのサービスでログイン」は、何を見て本人だと判断するの？

ペンギン先生

標準的な方法の一つは、OAuth 2.0に認証を加えたOpenID Connectだよ。APIを呼ぶアクセストークンとは別に、認証結果を伝えるIDトークンを使う。アプリは発行元、宛先、有効期限、署名などを規格に沿って検証するんだ。JWTはそのトークンの形式。文字列を読めるだけではログインを認めてはいけないよ。

ひよこ

アクセストークンが期限切れになったら、毎回ログインし直すの？

ペンギン先生

サービスがリフレッシュトークンを発行する場合は、それを使って新しいアクセストークンを取得できるよ。ただし発行されるとは限らず、有効期間も一律ではないんだ。漏えいに備えた更新時のローテーションなどの保護が必要で、利用者が連携を取り消した場合も再認可が必要になることがあるよ。

ひよこ

使う人と作る人は、何を確かめればいい？

ペンギン先生

利用者は連携先のアプリ名と求める権限を確認し、不要な連携を外そう。作る側は登録した戻り先の照合、PKCE、stateなどを用いたCSRF対策、トークンの検証と保管を確認するよ。必要な対策は構成で変わるので、公式SDKやライブラリの対応フローに沿って実装するんだ。OAuthは「何を許すか」、OIDCは「誰の認証結果か」と分けると整理しやすいね。

3種類の情報を分けて考える

図は、利用者が許可する認可コードフロー＋PKCEを簡略化しています。OAuthには利用者の操作を伴わない別のフローもあります。OIDCの利用者識別は発行元（iss）と利用者識別子（sub）を基準にし、メールアドレスだけを不変のIDだと思わないことも大切です。nonceを送った場合は、その値が応答と一致することも検証します。

次に読む：JWTの中身と署名の仕組み。

参考資料

確認日：2026年9月21日。

• RFC 6749 — OAuth 2.0 — 4者の役割、認可コードフロー、スコープ、任意のリフレッシュトークン。
• RFC 7636 — PKCE — code_verifierとS256によるcode_challenge、コード交換時の照合。
• RFC 9700 — OAuth 2.0 Security Best Current Practice — リダイレクトURIの照合、公開クライアントのPKCE、CSRF対策、リフレッシュトークンの保護。
• OpenID Connect Core 1.0 — IDトークンの役割、iss・aud・expなどの検証、subによる利用者の識別。