これは？
仕事でOAuth2.0プロバイダを構築する機会があったのでOAuth2.0について調べた事を記載しています。
OAuth2.0とは？
認証の仕組みではなく認可の仕組みです。
(OAuth2.0のRFCに認可フレームワークと書かれています)
認証と認可の違い
認証
**「誰であるか」**を確認すること
(例)webサービスへログインする際にID、パスワードを入力して本人であることを確認する。
認可
**「権限」**を与えること
(例)①東京から大阪までの新幹線のチケットを持っているのでその新幹線に乗る権限がある。(誰であるかは確認しない)
②管理者であれば〇〇という権限を付与する→管理者である証明として管理者のID、パスワードでログインする必要がある。
webサービスでは多くの場合に②のように権限を付与するために認証をおこなうため認可、認証と一緒に記述されるケースが多いです。
OAuth2.0でできること
アクセストークンを発行することでユーザが自分のID、パスワード を渡すことなく、
データへのアクセス権限を第三者のアプリケーションに許可することができる。
OAuth2.0のフロー
OAuth2.0には認可フローがいくつかあります。
1: Authorization Code Flow
2: Implicit Flow
3: Client Credentails Flow
4: Resource Owner Password Credentails Flow
5: Refrshing an Access Token
ここでは
1: Authorization Code Flow
2: Implicit Flow
について記載していきます。
Authorization Code Flow
まず、Authorization Code Flowについて記載します。
Authorization Code Flowは以下の図のような流れになります。
Authorization Code Flowの問題点
Clientがモバイルアプリを使用した場合、callbackURLを不正利用して認可コードを横取りすることができてしまうという点です。図で言うと「認可コードを発行します」の部分で本来Aというアプリに認可コードを返すはずが、Bというアプリに返すような不正ができてしまうということです。
対策
この対策としてPKCE(ピクシー)と呼ばれる認可コードの横取り対策をしたOAuthの拡張仕様が存在します。
簡単には新たにパラメータにcode_challenge_method、code_challenge、code_verifierを追加してこれを使用してClientが正しいか判断するという処理が追加されます。
具体的なフローの例は今回は記載しませんが興味ある方は調べてみて下さい！
Implicit Flow
続いてImplicit Flowについて記載します。
こちらはフローの図は割愛しますがAuthorization Code Flowと違うところは認可コード使ってアクセストークンを取得するというフローではなくそのままアクセストークンを返すという点です。
Implicit Flowの問題点
こちらはアクセストークンの横取りが可能という脆弱性があり非推奨となってきているので使わない方が良いでしょう
対策
こちらもPKCEを使うことで対策ができます。
最後に
以上のようにWebアプリケーション向けであればAuthorization Code Flow or PKCEを
モバイルアプリ向けではPKCEを採用するのが現状では良さそうだと思います。
また機会があればPKCEを実際に実装して記事を書きたいと思います！