ID本の読者の一人から、「なんでアクセストークンがいるの？パスワードを保存すれば良いのではないの？」というパワーワードを聞いた。そうか、そういえば、そういうベーシックなことを説明していなかったな。というわけで、改定の機会があったら加筆するとして、とりあえずブログにしておきます。
OAuthと２つのトークン
OAuthの登場者には、
- 保護対象リソース (Protected Resource)：アクセス制御がされるべきリソース
- リソース管理者 (Resource Owner) ：保護対象リソースに対するアクセスを決定することができる人または組織
- 認可サーバ (Authorization Server)：リソース管理者の指示に従って、クライアントにトークン（切符）を発行するソフトウェア
- クライアント (Client)：リソース管理者の許可のもとに保護対象リソースにアクセスして何らかの処理を行うソフトウェア
- ユーザ・エージェント(User-agent)：ブラウザなどユーザであるリソース管理者がシステムと対話するのに使うソフトウェア
の５つのアクターがいます。
OAuthフレームワークは、リソース管理者 がクライアントに出した、リソースアクセスに関する許可 (Grant) を、保存可能な２種類の「トークン（切符）」として認可サーバが発行し、それを受け取ったクライアントがそれらを保管、そのうちの一つの「アクセストークン」を使ってリソースにアクセスする方法を取りまとめたフレームワーク（枠組み）です。IETFという標準化団体が定める文書、RFC6749とRFC6750によって基本が定められています。
２種類のトークンとは、アクセストークンとリフレッシュトークンです。クライアントはこれらを保存して後から使います。
アクセストークンは、リソースアクセスのために使われるトークンです。必要な最低限の権限を表しています。使用先＝受取者はリソースです。複数のリソースに対して使われるのと、通常リソースの保護レベルは認可サーバの保護レベルより低いため、漏洩のリスクがそれなりにあります。また、通常持参人式トークン（Bearer Token）ですから、盗まれたものも使えてしまいます。このリスクを下げるために、短期間しか有効でなくすることが多いです。
もう一つのトークン＝リフレッシュトークンは、認可サーバに対してしか使われません（使用先＝認可サーバ）。なので、盗まれる可能性は低いです。しかも、使用者制限トークン（Sender Constrained Token）ですので、盗まれても、クライアントクレデンシャルも一緒に盗まれないと使えませんので、盗難・使用リスクがアクセストークンに比べて著しく低いのが特徴です。そのため、長期間有効にするのが一般的です。クライアントは、このリフレッシュトークンを使って、新しいアクセストークンを取得することができます。アクセストークンを洗い替える（refreshする）から、リフレッシュトークンと言います。
この辺りについてアニメーションも使って説明した動画は以下に作ってあるのでご覧ください。
パスワード保存じゃダメなの？
さて、冒頭の質問についてです。どうも、こんな面倒くさいことやらなくても、クライアント（ネットワーク上にある共有クライアント）はそれぞれのリソース管理者のユーザ名とパスワードを保管しておけば、リソースにはアクセスできるじゃないか。OAuthなんかいらないじゃないか、という話のようです。（このリソースは、ユーザ名とパスワードを受け取ってユーザを受け入れるwebインターフェイスも持っています）
ダメな理由はいくつも挙げることができます。
- パスワードを保管するやり方は、リソース管理者の持つ全権限をクライアントに与えることになる。クライアントに限定的な権限移譲をすることができない。（最小アクセス権限の原則違反）
- リソースからすると、アクセスしに来ているのがリソース管理者なのか、クライアントなのかわからない。その為、有効にリスク管理をすることができなくなる。（なりすまし禁止原則違反）
- リソースを高度認証（パスキーなど）で守ることができなくなる。（適切な認証強度原則違反）
- ネットワーク上で可逆な形で複数のリソース管理者のパスワードを保管しなければならず、漏洩リスクが看過できない。（パスワードの可逆保管禁止原則違反）などなど
もういいですよね？パスワード保存ではダメなんです。
マックで二人のJKが話してた版
なんか硬いなーというので、Claude.ai に「マックで二人のJKが話してた版」を作ってもらったのでよろしくご査収ください。
まい: ねぇねぇ、さっきネットで見たんだけどさ、ヤバくない？
ゆか: なになに？どんな話？
まい: なんか、WebアプリがOAuth使う代わりにみんなのパスワード保存しちゃえば、サイトで何でもできるし作るのも簡単だし便利じゃね？って。
ゆか: えぇ！？それってマジやばくない？
まい: そうそう！でもさ、それって全然ダメなんだって。
ゆか: え、なんで？便利そうじゃん。
まい: いやいや、理由がいっぱいあんだって。まず、パスワード預けちゃうと、そのWebアプリに全部お任せみたいになっちゃうんだって。
ゆか: うわ、それヤバすぎ！制限とかつけられないじゃん。
まい: そうそう！んで、サイトからしたら、誰がアクセスしてきてんのかわかんなくなるんだって。
ゆか: マジで？本人なのかWebアプリなのか、めっちゃ混乱しそう。
まい: しかも、パスキーとかの超かっこいい認証方法も使えなくなっちゃうんだって。
ゆか: えー、それダサすぎない？
まい: でしょ？最後に一番やばいのが、ネット上にみんなのパスワードがバレちゃう形で保存されちゃうんだって。
ゆか: うわぁ、それ超怖い！もう絶対ダメじゃん。
まい: そうそう！だからWebアプリにパスワード保存とか、マジありえないんだって！
ゆか: なるほど〜。ちゃんとOAuthした方がいいってことね。勉強になった〜！
@_Nat Zoneをもっと見る
購読すると最新の投稿がメールで送信されます。