OAuthについて

Last updated at 2025-05-10Posted at 2025-04-20

OAuthとは

Open Authorizationの略
認可プロトコルで、オンライン認可の業界基準。
最新バージョンは2.0

異なるサービス間での認証や情報共有を安全に、かつ簡単に行うための標準プロトコルで、多くのWebサービスやアプリケーションで使用されている。

活用事例
ユーザーが自分のアカウントパスワードを共有せずに、サードパーティのアプリケーションに自分のデータ（X、Googleなど）へアクセスできる

Google, Facebookなどのソーシャルログイン（ID,PWが不要でログインできる）など

ユーザビリティの向上
ユーザーは新たにユーザー名やパスワードを覚える必要なく、既存のソーシャルメディアアカウントを使用してサービスにログインができ、ユーザー体験が向上する。
登録の簡素化
新規ユーザーは、ソーシャルメディアアカウントを使用して簡単に登録できる。これにより、登録プロセスが簡素化され、ユーザーの離脱率低下に貢献。
セキュリティの強化
パスワードを直接管理する必要がなくなるため、パスワードリセットやパスワード盗難のリスクが減少します。また、ソーシャルメディアプロバイダーは通常、セキュリティ対策（例えば二段階認証）を提供しています。

リソースオーナー（ユーザー）
リソースの持ち主で、アクセスを許可する
クライアント（アプリ、バックエンドAPIなど）
リソースオーナーに代わり、リソースへアクセスを要求する
認可サーバー（X API、Google APIなど）
リソースオーナーを認証し、クライアントにアクセストークンを発行する
OAuth2.0において最も重要な役割を果たす
このサーバーは、クライアントからのアクセストークンのリクエストを受信し、認証が成功してリソースオーナーから合意を得たら、アクセストークンを発行します。
認可サーバーは、2つのエンドポイントを公開します。
・認可エンドポイント：インタラクティブな認証とユーザーの合意を取り扱う
・トークンエンドポイント：マシンtoマシンに関与する
リソースサーバー（X、Googleなど）
リソースを管理する

^{*認可サーバーとリソースサーバーは同一のシステムで統合されてるケースも多い}

クライアントがアクセストークンを取得する方法

認可サーバーに認可リクエストをして、成功するとアクセストークンを発行するための認可コードを発行してくれる。クライアントはそれを使ってアクセストークンを取得する

認可コードはアクセストークンの引換チケットのようなもの。

ただ、なぜアクセストークンを直接返さないのか？の理由は盗難リスクに備えて、そういう設計になっている。
実際に認可コードはセキュリティを高めるために以下のように設計されている
・有効期間が短い
・1回しか使えない

*インプリシットグラントだと、認可コードなしに直接アクセストークンが付与される

*PKCEについて
PKCE（Proof Key for Code Exchangeの略で、呼び方はピクシー）は、OAuth2.0の拡張使用で、認可コード横取り攻撃を防止するセキュリティの強化手法。認可コードフローのフロー自体を変えるものではなく、認可コード横取り攻撃への対策を追加する。

アクセストークン
クライアントがリソースサーバーへリクエストするために必要

リフレッシュトークン
アクセストークンには期限があり、基本的に短いので期限が切れたら新しいアクセストークンを取得するのに、このリフレッシュトークンが使用される。
アクセストークンと一緒に発行されるが、リソースへのアクセスには使わない、あくまで更新の為に使う。

*アクセストークンの期限が短くしてあるのは悪用を防ぐため

こちらの記事で、OAuth2.0フローPKCEで X APIのアクセストークンを実際に取得する流れ、PKCEの詳細などを記事にしています。