OAuth認証の脆弱性とOpenIDConnectでなぜ解決されるのか分かりやすく解説
概要
OAuth認証に脆弱性があり、認証にはOpenIDConnectを使うべきであることは、なんとなく知っているけど、そもそもなぜ脆弱性があり、そしてOpenIDConnectでなぜ解決されるのかわからない人のために分かりやすく解説します。
この記事ではOAuth認証の脆弱性とOpenIDConnectがそれを解決する理由にフォーカスするために、OAuthのOpenIDConnect自体の説明は簡略しています。
この記事で伝えたいこと
- Oauthをざっくり解説
- OAuth認証の脆弱性の理由
- OpenIDConnectをざっくり解説
- OpenIDConnectがOAuth認証の脆弱性を解決する理由
OAuthをざっくり解説
詳しく知りたい場合、この記事を読むのがいいです。
今回は結論まで早くたどり着くためにざっくりとだけ解説します。
こんな感じの絵になります。外部サービスはTwitterとかをイメージしてください。
OAuthとはざっくりとはこのような説明になります。
- ユーザーを外部サービスにリダイレクト
- ユーザーはそのサービスの認証情報を入力
- ユーザーがリダイレクトされて帰ってくる。認可コードも渡される
- 認可コードをアクセストークンと交換
- アクセストークンを使うと外部サービスに保存されているユーザーのリソースにアクセスできる
OAuth認証とその脆弱性
OAuthを使ってTwitterなどの外部サービスと連携できるようになると、「認可コードを使ってTwitterからTwitterのユーザーIDを取得してログインに使おう」ということを思いつきます。
これがOAuth認証と呼ばれるものの一つの例になります。
OAuth認証には脆弱性があることが知られていて、以下の記事が有名です。
要するにどういうことかというと
- 悪い人がレシピサイトの偽サイトを作る
- 偽レシピサイトの中でAさんがTwitter連携する
- 悪い人BさんはAさんのアクセストークンを得る
- 本当のサイトに行ってAさんのアクセストークンを使うとAさんになりすますことができる
なぜ脆弱性が生まれるのか
アクセストークンが偽レシピサイト/レシピサイトのどちらに対して発行されているのか見ていない
からになります。
OpenIDConnectではこの問題を解決することでOAuth認証の脆弱性を解決しています。
OpenIDConnectをざっくり解説
詳細な説明はこちらの記事が一番分かりやすいです。
OpenIDConnectにはOAuthと比較してトークン発行までのフローの種類が多いですが、基本的にはOAuthと同じフローで発行されると考えて問題ありません。
これは認可コードフローというフローに限った話ですが、説明のためにこのフローだけに絞ると、OAuthではアクセストークンだけもらえていたのに対して、OpenIDConnectではアクセストークンとid_tokenの両方が発行されます。
OAuth認証では認可のためのトークンであるアクセストークンを認証に使っていましたが、認証のためのトークンであるid_tokenを認証に使うようにします
認証の方が認可よりもセキュアな仕組みが求められるという理解だけでここでは大丈夫です。
参考
- https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47
- https://dev.classmethod.jp/articles/authentication-and-authorization/
OpenIDConnectがOAuth認証の脆弱性をどう解決するのか
なぜOAuth認証の脆弱性がOpenIDCOnnectで解決されるのかを考えるためにはOAuthとOpenIDConnectの差分を考えるのが分かりやすいです。
OAuthとの差分としてはOpenIDConnectでは以下の検証を行うことで、トークンの改竄を防ぎ、「誰が誰に対していつ発行したものか」を検証できる仕組みが導入されています。
- 署名の検証
- iss(発行者）, aud(発行された者）,exp(有効期限）の検証
そのため例えば偽サイトを作ってid_tokenを盗んだところで、その「id_tokenは偽レシピサイトに対して発行された」トークンなので本物のレシピサイトでは使うことができません。
このようにid_tokenを認証に使うことでOAuth認証よりもセキュアな認証を行うことができ、脆弱性の問題を解決することができます。
まとめ
OAuth認証に対してOpenIDConnectでは
- 署名の検証
- iss(発行者）, aud(発行された者）,exp(有効期限）の検証
を行いトークンの改竄を防ぎ、「誰が誰に対していつ発行したものか」を検証できる仕組みが導入することで脆弱性の問題を解決しています。
Discussion
この成り立ちはどこかに記載がありますか？
もともと
として別々で同時期に仕様策定が進められていたものを、共通する要件などを踏まえてOIDCがOAuth 2.0ベースでIdentity Layorを載せたもので行くと方針を変更したものです。
なので、OIDCがOAuth認証の脆弱性云々の話とするのは正しくないと思います。
記載場所は覚えていないのですが、勉強するうちに誤解していました。
記事を修正いたしました。