OAuthは認証ではなく認可の仕組みである 🔑

Last updated at 2025-09-30Posted at 2025-09-20

まとめ

以下がスライド版です！

背景

先日以下の記事を元にしたLTで質問をいただきました。

LTイベントはこちらでした。

普段Googleでログインとか、GitHubでログインとか、他のサービスのアカウントでログインするときに使われている技術という理解であってますか？？

この質問に対して上手く回答ができなかったです。
OAuthが認証そのものの仕組みなのかについて整理したいと思います。

認証は通常、ユーザーがアプリケーションにユーザーIDやパスワードというクレデンシャルを提示します。それによって自分がそのアプリケーションのユーザーであることを証明します。

認可とは何ができるか（リソースを利用すること）を許可する仕組みのことです

ここでいうクライアントとは
ユーザーのデータ（リソース）を使いたいアプリのこと、フロントエンドの意味で言うクライアントのことではない

しかし、OAuthのクライアントは誰が自身の要求を認可をしたのかを把握していません。
OAuthのクライアントの役割はトークンを問い合わせて、トークンを取得して、そのトークンを使ってAPI（リソース）にアクセスすることです。

つまり、以下の仕組みでOAuthがクライアントの認証システムに利用されるということがわかります。

この仕組みの例）GoogleのOAuthを利用したログイン済みユーザーを認証する仕組み

もう少しイメージが掴めるように図示しました。

語句説明

リソース所有者:ユーザー本人
保護対象リソース:ユーザーのデータを持っているサービス

認可サーバーとは

余談：本の一文が理解できなかった話

「Web API: The Good Parts」を読んだ時に以下の文があり、自分は最初読んだ時にあまりイメージがついていませんでした。

提供するAPIの認証システムとしてOAuthを利用する

しかし、以下の記事を読んで腑に落ちました。

Googleのユーザ情報を取得するAPIの操作を認可し、その情報を使って・認証ログインをしていたという仕組みです。

この記事では「Googleログイン」を例に説明されていて、

という流れでした。

つまり、OAuth自体は認可の仕組みだけれど、認証に“利用される”ことがあるということでした。

OpenID Connect（OIDC）はOAuthを基盤とした認証プロトコルです。
次回の記事でまとめたいと思います。

クライアントが提供するAPIの認証システムの一部にOAuthが利用される

OAuthは認証の仕組みそのものではなくて認可の仕組みそのものである