OAuthとは？

読み方：oauth

最終更新：2026/08/18

3秒でわかる

パスワードを渡さずに、別サービスのデータへのアクセス権だけを他のアプリへ委譲する仕組み。ソーシャルログインの土台にもなっています。

30秒図解

OAuthは認可コードをアクセストークンへ交換し、パスワードを渡さずにAPIへアクセスする流れ — OAuthでは利用者のパスワードをアプリへ渡さず、許可された範囲と期限を持つアクセストークンでAPIを利用します。

もう少し詳しく

どういうものか

OAuth は、あるサービスが持つ利用者のデータに、別のアプリが利用者本人の同意のもとでアクセスするための取り決めです。要点は、アプリが利用者のパスワードを預からないことです。代わりに、権限の範囲と期限が限定されたアクセストークンを受け取ります。現在広く使われているのは OAuth 2.0 です。

登場人物は 4 つあります。データの持ち主である利用者 (リソースオーナー)、アクセスしたいアプリ (クライアント)、同意を取ってトークンを発行するサーバ (認可サーバ)、データを保管しているサーバ (リソースサーバ) です。

なぜ必要か

OAuth が無かった時代は、外部サービスに Google のパスワードを入力させて連絡先を読み込む、という作りが実在しました。これでは権限を絞れず、退会してもパスワードが相手に残り、パスワードを変えれば連携が全部切れます。

トークンなら、範囲を「連絡先の読み取りのみ」に絞れ、期限を数時間に切れ、利用者はいつでも取り消せます。渡すものを鍵そのものから、用途限定の入館証に置き換えたのが OAuth です。

具体例

もっとも使われる認可コードフローの流れは下記のとおりです。

利用者 ─▶ アプリ「Google で続ける」を押す
アプリ ─▶ 認可サーバへ<a href="/glossary/redirect" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">リダイレクト</a> (client_id, scope, redirect_uri, state)
利用者 ─▶ 認可画面で同意
認可サーバ ─▶ アプリへ認可コードを付けて戻す
アプリ ─▶ 認可コード + client_secret をサーバ間で送る
認可サーバ ─▶ アクセストークンを返す
アプリ ─▶ トークンを付けて <a href="/glossary/api" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">API</a> を呼ぶ

<a href="/glossary/curl" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">curl</a> -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  https://api.example.com/v1/me

似た用語との違い

OAuth が扱うのは認可 (何をしてよいか) であって、認証 (誰であるか) ではありません。ログインに使いたい場合は、OAuth の上に本人確認の層を重ねた OpenID Connect を使い、アクセストークンではなく ID トークンで利用者を識別します。アクセストークンを持っていることを本人確認の代わりにすると、他のアプリ向けに発行されたトークンを持ち込まれたときに、別人としてログインを通してしまいます。