今回は、 Fitbit API を利用する際に OAuth 2.0 PKCE というものが出てきたので、調べてみた結果をざっくりとまとめてみました。
シーケンス図の上下の余白について
この記事に掲載されているシーケンス図は、 Mermaid構文 を利用して生成されています。
横に長くなりすぎた為なのか、シーケンス図の上下に余分な余白が発生してしまっています。
height が固定値で入ってしまっているので、調整が出来ませんでした。
見ずらいとは思いますが、ご了承のほどよろしくお願いいたします。
改善されました！
ご対応ありがとうございました。
https://github.com/increments/qiita-discussions/discussions/481
OAuth 2.0 の許可コードの取得方法って何があるの？
OAuth 2.0 を用いた許可コードの取得方法は、大雑把に分けると下記の2つが挙げられます。
最近の API では OAuth 2.0 PKCE（RFC7636）を用いた認証フローが推奨されています。
前述の Fitbit 以外では LINE や Yahoo! でも導入されています。
（PKCE は ピクシー と発音します。）
そもそも何で、2種類あるの？
結論から言うと、 OAuth 2.0 では認証の許可コードが悪意あるアプリに横取りされる可能性があるからです。
認証の許可コードの横取り攻撃について
OAuth 2.0 を用いた認証フローでは、API連携のためのログインおよび許可後、許可コードが発行されて、コールバックURLへリダイレクトされます。
事前にコールバックURLをアプリに紐付けておくことで、アプリ側で許可コードが取得できるようになります。
この際、アプリとコールバックURLを紐付ける方法として、 カスタムURLスキーム というものが用いられます。
カスタムURLスキームとは、 apps:// というようなURLのことで、このURLにアクセスすると、事前に設定されたアプリが開くようになっています。
カスタムURLスキームは、他のアプリと同じものを指定することが出来てしまうため、開発者側でどのアプリを開かせるかまではコントロールできません。
悪意あるアプリは、カスタムURLスキームをターゲットとなる他のアプリに偽装し、成りすますことで許可コードを奪取しようとします。
OAuth 2.0 認証について
OAuth 2.0 と OAuth 2.0 PKCE の違いや横取り攻撃について理解するために、まずは OAuth 2.0 の通常の認証フローと悪意あるアプリが認証コードを奪取しようとする際のフローをシーケンス図で見てみましょう。
通常の OAuth 2.0 認証フロー
まずは Fitbit API を例にした通常の OAuth 2.0 認証フローです。
悪意あるアプリにアクセストークンを奪取されてしまった場合の OAuth 2.0 認証フロー
次に Fitbit API を例にした悪意あるアプリにアクセストークンを奪取されてしまった場合の OAuth 2.0 認証フローです。
OAuth 2.0 PKCE 認証について
上記の認可コードの横取り攻撃を阻止する方法として、考えられたのが OAuth 2.0 PKCE（RFC7636）認証フローです。
PKCE の特徴は、許可コードのリクエストを行うサーバー側で事前に code_verifier と code_challenge と呼ばれるものを生成します。
code_verifier と code_challenge のそれぞれの特徴は下記のとおりです。
- code_verifier： 43～128文字から構成されるランダムな文字列です。
- code_challenge：
code_verifierをSHA256でハッシュ化し、Base64 URL Encodeしたものです。
認証フローでの特徴は、下記のとおりです。
- OAuth サーバーへの許可コードのリクエスト時に、
code_challengeを送ります。 - OAuth サーバーでは
code_challengeを保存した上で、許可コードを発行します。 - 発行された許可コードとアクセストークンの引換のリクエスト時に OAuth サーバーに
code_verifierを送ります。 - OAuth サーバーでは、送られてきた
code_verifierからハッシュ値を計算し、事前に受け取っていたcode_challengeと計算したハッシュ値が一致するかを検証します。 - ハッシュ値が一致した場合はアクセストークンを発行し、返します。
こちらも先程同様にシーケンス図で見てみましょう。
OAuth 2.0 PKCE 認証フロー
まずは Fitbit API を例にした通常の OAuth 2.0 PKCE 認証フローです。
悪意あるアプリがアクセストークンの奪取をしようとした場合の OAuth 2.0 PKCE 認証フロー
次に Fitbit API を例にした悪意あるアプリがアクセストークンの奪取をしようとした場合の OAuth 2.0 PKCE 認証フローです。
まとめ
PKCE を用いた認証を行うことで、悪意あるアプリに認証コードを奪取されたとしても、 OAuthサーバーに保存されている code_challenge の元になっている code_verifier が、悪意あるアプリには分からないため、アクセストークンの取得を阻止できます。
ただし、 code_verifier は正規のアプリしか知り得ない前提となっているため、 code_verifier が外部に漏れてしまうと横取り攻撃をされるリスクが生じます。
従って、 code_verifier 及び code_challenge は一意のものを利用するのではなく、認証コードのリクエストごとに生成し直す必要がある点に注意が必要です。
参考文献
下記のサイトを参考にさせて頂きました。