OAuthについて他人に説明する機会があったので、まとめてみました。
認証（Authentication）
認証は誰であるかを確認することです。
例えば、パスワード認証。
その人しかしらないパスワードがわかるならそれは本人です。
例えば、指紋認証。
生体的特徴が一致するならそれは本人です。
認可（Authorization）
認可とは権限をあたえることです。
認証と認可はセットになっていることが多いです。
ATMからお金をおろすにはキャッシュカードとパスワードが必要です。
キャッシュカードで口座を特定し、パスワードでキャッシュカードの持ち主本人かを認証し、口座からお金をおろす許可を与えています。
認証のない認可の例としては、電車の切符があります。
切符を持っていれば電車に乗る許可が与えられますが、切符を持っている人が誰かを確認したりはしません。
APIへの認可
たとえば、クライアントアプリ用のAPIを作ったとします。
でも、APIを無制限に公開すると悪い人がアプリ以外からAPIを実行してしまいます。
なので、アプリ内に秘密の鍵を持たせて、鍵が一致しないアクセスを弾くことにします。
アプリは認可されており、悪い人は認可されていない状態です。
次にこのAPIでユーザー毎のデータを管理することを考えます。
このアプリの利用者にみんなに同じ鍵を付与したままだと、違うユーザのデータでも更新したり閲覧したりできてしまいます。
そこで、同じアプリでもユーザ毎に違う鍵を付与することにしましょう。
各ユーザは自分のデータのみについて更新権限が付与されました。
OAuth
OAuthは上の図の認可の仕組みを標準化したものです。
認可を与えるためのAuthサーバが登場し、鍵の代わりにアクセストークンを付与します。
OAuthには色々な方式の認証フローがありますが、以下はImplicitフローと呼ばれる簡易な方式です。
OAuthによる認証
OAuthは認可のための仕組みでしたが、それを認証にも使っちゃおうという考えです。
GoogleでログインとかFacebookでログインとかよくあるあれです。
OAuthを認証につかう危険性1
単なる OAUTH 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
アプリAが悪意を持っていた場合、アプリAがユーザAにもらったトークンでアプリBにログインし、
アプリB内のユーザAの情報を閲覧・更新できてしまいます。
なぜ、こんなことが起きるかといえばOAuthが認可の仕組みだからです。
アクセストークンには認証機能がありませんから持ち主が誰かは気にしません。
アプリBがOAuthをログインに使ってさえいなければ、
アプリAはユーザAにもともと許可された範囲の情報にしかアクセスできず問題はなかったのです。
OpenID Connect
OpenID ConnectはOAuth2.0の仕組みに認証の機能を追加したものです。
OpenID Connectではアクセストークンと一緒にIDトークンを返却します。
IDトークンには認証に必要な様々な情報が含まれており、IDトークンを検証することでOAuthで問題となっていた脆弱性の多くを解決することができます。
IDトークンの検証例 ＞ Yahoo! ID連携 IDトークンの検証
例えば、先程のOAuthでの問題は、以下の検証で検知できます。
対象のウェブサイトやアプリケーションと異なるサービスに発行されたID Tokenでないことを確認するために、Payloadのaud値に対象のウェブサイトやアプリケーションに発行されたClient IDの値が含まれていることを検証します。
その他
リフレッシュトークンとか、クライアントシークレットの問題点などについても追記したい。