OAuth 2.0は2012年にRFC 6749として標準化された、認可（Authorization）のためのプロトコルです。「他社サービスに自分のデータへのアクセスを許可するとき、パスワードを渡さずに済む」という発想で生まれ、「Googleでログイン」「GitHubで連携」のような体験を支える土台になっています。認証（誰か）ではなく認可（何ができるか）を扱うプロトコルである点を最初に押さえておきましょう。
この記事の目次
- OAuth 2.0の主要登場人物
- 代表的なフロー
- OAuth 2.0とOpenID Connect
- セキュリティ上の注意点
- まとめ
OAuth 2.0の主要登場人物
OAuth 2.0には主に4つの登場人物がいます。Resource Owner（本人ユーザー）、Client（許可を求める3rdパーティアプリ）、Authorization Server（許可を発行するサーバ＝Google等）、Resource Server（実際にデータを持つAPI）。
本人は Authorization Server に「このアプリにこの権限を与えていいですよ」と同意し、ClientはアクセストークンをもらってResource Serverへアクセスする、という構図です。「鍵束を渡す代わりに、限定的な合鍵を出す」イメージが分かりやすい比喩です。
代表的なフロー
OAuth 2.0には複数のフロー（Grant Type）があり、Clientの種類に応じて使い分けます。サーバサイドWebアプリは Authorization Code フローが基本、モバイル/SPAは PKCE 付きの Authorization Code フロー、サーバ間連携は Client Credentials フロー、というのが現代の標準です。
古い Implicit / Resource Owner Password Credentials フローは脆弱性の懸念があるため非推奨化が進んでおり、OAuth 2.1（草案）では削除される予定。新規実装ではPKCE付きのAuthorization Codeを使うのが最も安全です。
OAuth 2.0とOpenID Connect
OAuth 2.0は認可プロトコルなので、「このトークンを持っているのが誰か」までは規定しません。ここを補うのがOpenID Connect（OIDC、2014年標準化）で、OAuth 2.0を拡張して認証情報（IDトークン）を運べるようにします。
「Googleでログイン」「Microsoftでログイン」のようなフェデレーション認証はOIDCが裏で動いています。OAuth 2.0 = 認可、OIDC = 認証、と覚えると整理しやすくなります。
セキュリティ上の注意点
OAuth 2.0は柔軟な反面、実装ミスがそのままセキュリティ事故に直結します。Redirect URIの厳密チェック（オープンリダイレクト防止）、State パラメータでのCSRF対策、PKCEの導入、アクセストークンの有効期間を短くしてRefresh Tokenで延長する設計などが基本です。
可能な限り認証基盤は自作せず、Auth0 / Okta / Firebase Authentication / Amazon Cognitoなどの既存ID基盤を使うのが定石。OAuth 2.0は仕様が複雑で、自前実装で穴を作るリスクが高い領域です。
まとめ
OAuth 2.0はモダンWeb・モバイルの認可基盤として欠かせないプロトコルです。OpenID Connectと併せて押さえると、Web開発における認証認可の地図がはっきり見えます。「Googleでログイン」の裏側を理解できる開発者を目指しましょう。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント