ユーザーの認可にはOAuthを用いるのが一般的です。OAuthではアクセストークンをやりとりしますが、OAuth標準の仕様だと、悪意のある第三者にアクセストークンを取得されるおそれがあります。

これを防ぐのがPKCEです。アプリケーションをPKCEに対応することで、第三者によるアクセストークンの取得を防ぐことができます。この記事では、OAuthによる認可機能の実装をより安全にするためのPKCEという仕様の概要と実装例を示します。

Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

Follow @zenizh

PKCEは「アクセストークンを安全にやり取りするための、OAuth 2.0の拡張仕様」です。Proof Key for Code Exchangeの略で、意訳すると「安全にコードをやりとりするための証明鍵」となります。

PKCEは2015年9月にRFC7636として定義されています。「ピクシー」と発音します。

OAuthを用いた一般的な認可のフローを見てみます。ユーザーがアプリにアクセスすると、認可を求められます。ユーザーは認可サーバー上で認証を行い、成功すると認可サーバーからアプリ側にコードが渡ります。

アプリは受け取ったコードを元に、認可サーバーからアクセストークンを取得します。あとはアクセストークンを元にプロフィール情報などを取得して、ユーザーに画面を表示します。これが一般的な認可のフローになります。

一般的な認可のフローでは、手順5でアプリがコールバックを受け取っています。このコールバックを、「悪意のあるアプリ」に取得されてしまった場合のフローを見てみます。

ユーザーが認可サーバー上で認証を行うまでは同じですが、認証後にアプリではなく第三者にコールバックが渡ってしまいます。

このコールバックには、アクセストークンを取得するためのコードが含まれています。つまり、第三者がアクセストークンを取得できてしまいます。アクセストークンがあれば、ユーザーの個人情報を取得したり、機能を操作することができてしまいます。これを防ぐのがPKCEという仕様になります。

上のフロー図で「悪意のあるアプリ」というのが出てきました。この第三者は、どうやってコールバックを取得するのでしょうか。

具体的にはカスタムURLスキームを利用する方法があります。例えばiPhoneでは、ブラウザにmusic://というURLを入力するとMusicアプリを起動できます。このようにURLの形式で任意のアプリを開くのがURLスキームです。

ただ、開発者が設定できるカスタムURLスキームでは、どのアプリを開くかまでは特定できません。つまり、あなたのアプリがfoo://というURLスキームでの起動を想定しても、実際には第三者のアプリが起動する可能性が出てきます。

第三者があなたのアプリのfoo://から始まるコールバックを取得してしまった場合、認可サーバーから第三者のアプリが起動されることになります。これがアクセストークンの流出につながります。

上述した、悪意のあるアプリへの対策がPKCEです。PKCEに対応した場合の認可のフローを見てみます。

ユーザーがアプリにアクセスすると認可を求められます。このとき、アプリ側ではcode_verifierとcode_challengeという二つの文字列を生成します。

アプリはcode_challengeを認可用URLに含めることで認可サーバーに送ります。認可サーバー側で、このcode_challengeを保管しておきます。あとは、アクセストークンをリクエストするときにcode_verifierを付け加えます。認可サーバーはcode_verifierが正しいかどうかを、保管しておいたcode_challengeを元に検証します。

code_verifierが正しければアクセストークンを返却し、間違っていれば何も返しません。code_verifierは正規のアプリしか知ることはないので、第三者にアクセストークンが横取りされることがなくなる、という仕組みです。

PKCEに対応したアプリに対して、悪意のあるアプリが横取りを試みるフローを見てみます。第三者がコールバックURLを取得できたとします。この場合でも、第三者がcode_verifierを知ることができません。

認可サーバーはリクエストのcode_verifierを元に検証を試みますが、正しい値ではないため検証に失敗します。つまり、アクセストークンが返されることはありません。

次に、PKCEに対応するための具体的な実装例を見てみます。ここでは参考実装として、Rubyのコードを示します。PKCE対応において重要なのはcode_verifierとcode_challengeの生成です。この二つの仕様は次の通りです。

実装例は次の通りです。

# code_verifier
code_verifier = SecureRandom.alphanumeric(64)

# code_challenge
code_challenge = Base64.urlsafe_encode64(OpenSSL::Digest::SHA256.digest(code_verifier), padding: false)

この二つの文字列を説明するために、以下にPKCE対応のフロー図を再掲します。

ここでいう認可用URLのパラメータとしてcode_challengeを付与します。また、あわせてcode_challenge_methodという値も含めます。code_challenge_methodは「code_verifierをどんな方法で暗号化したか」で、SHA256を表すS256という文字列で固定します。

https://xxx/authorize?xxx=xxx&code_challenge=abcdefg...&code_challenge_method=S256

あとは、アクセストークンのリクエスト時にcode_verifierを含めるだけです。

$ curl -v -X POST https://xxx/access_token \
       -d 'xxx=xxx' \
       -d 'code_verifier=123456...'

こうすることで、認可サーバー側でcode_verifierを検証してくれます。アプリ側の実装としては、やることは以上になります。これだけで、第三者によるアクセストークンの横取りを防ぐことができます。

PKCEの仕様は2015年9月に策定され、各社が対応しています。例えば認証サービスのAuth0では、モバイルアプリでのPKCE対応を必須、SPAでも推奨としています。

Yahoo! IDでもPKCEへの対応が可能になっており、またLINEの認証サービス「LINEログイン」でもPKCE対応が推奨されています。Rubyの認可ライブラリ「OmniAuth」では、オプションでPKCEを有効化できます。

インターネットの標準化団体であるIETFのOAuth 2.0 Security Best Current PracticeでもPKCE対応についての記述があるように、PKCEに対応することでより安全なアプリをユーザーに提供することができます。

プロダクト開発

【2023年】エンジニアの本でおすすめの5冊を紹介します

2023-4-2

働き方

エンジニアの転職で登録したい7つの転職サイトと転職エージェント

2022-12-30

働き方

エンジニアの副業で登録したい5つのサイトやサービス【フリーランス】

2022-12-30