はじめに
Web API のセキュリティ周りについて調べていると、
「OAuth 2.0」や「OpenID Connect」という単語をよく見かけると思います。
さらに調べると、「アクセストークン」と「IDトークン」という単語に出会いました。
しかし、この2つのトークンの違いについて、
いまいち理解ができていなかったので、今回は両者の違いを調べてみました。
加えて、トークンについて調べる中で、
OpenID Connectが生まれた経緯も知ることができたのでメモしておきます。
2つのトークンの違い
アクセストークン と IDトークン、両者は役割が大きく異なります。
- アクセストークン：認可（リソースへのアクセスコントロール＝あるリソースへの権限（readやwriteなど）を持っているかどうか確認すること）
- IDトークン：認証（その人が誰かを確認すること）
名前のままでした。
認可に使うためのいろいろな情報が詰まっているのがアクセストークンで、 認証に使うためのいろいろな情報が詰まっているのがIDトークンです。
OpenID Connectが生まれた経緯
OAuth 2.0およびOpenID Connectについて調べていると、
「OpenID Connect は OAuth 2.0 を拡張した仕様」であるという記述を見かけました。
どうしてOpenID Connectが必要になったのか、
この辺の経緯について述べていきます。
OAuth 2.0 は 認可 の仕組み
まずは、OAuth 2.0について見ていきます。
OAuth 2.0 は 認可 の仕組みであり、 認証 の仕組みではない
のですが、実際にはOAuth 2.0を認証用途で使っているシステムは多く存在します。
OAuth 2.0 で認証を行うことの問題点については、
こちら
の記事に詳しく書いてあります。
上記記事より、OAuth 2.0 による認証の問題点は、
クライアント（アプリケーション）側でトークンの正当性を確かめる術がない ことであるとわかります。
なお、ここでいう「正当性」に関して補足しておくと、
「正当なトークン」とは、クライントが受け取ったトークンがそのクライアントのために用意されたものであることを意味します。
つまり、クライアント側でトークンの正当性を確かめる術がない＝クライアントが自身のためのトークンであることを検証する術がないという意味です。
（トークンの改ざん検知うんぬんの話ではありませんのでご注意ください）
「OAuth 2.0 による認証の問題点」という言葉を使っていますが、先述のとおりOAuth 2.0は認可のための仕組みなので、厳密には「認証の問題」なんて存在しません。 説明しやすくするためにこういった言葉を使っています。
クライアント側でトークンの正当性を確かめたい
OAuth 2.0 による認証の問題は OpenID Connect に則ることで解決できます。
では、どうして OpenID Connect を使うと安全に認証できるようになるのでしょうか。
キーとなるのは IDトークン に含まれる audクレーム です。
audクレーム
audクレーム は IDトークン に含まれるデータのひとつです。
（「クレーム」はJSONにおける「キー」とほぼ同義だと思ってください）
では、この audクレーム がどういった情報を持っているかと言うと、
そのトークンがどのクライアントのために発行されたものか という情報です。
したがって、audクレームを使用することで、
クライアントは自身のためのトークンかどうか調べることが可能です。
この「クライアント側で audクレーム のチェックを行う」ことは仕様として決められています。（参考 ）
このような仕組み（ルール）があるから、
OpenID ConnectでOAuth 2.0 による認証の問題を解決できるわけですね。なるほど
まとめ
- アクセストークンは認可、IDトークンは認証に使うもの
- 認証がしたいなら OpenID Connect を使いましょう
今回の内容は、自分が調べたことをだいぶざっくりメモした程度のものです。
下記に参考記事を載せておくので、詳細はそちらを御覧ください。
