開発基盤部会 Blog

開発基盤部会 Blog
12345
2019/07/17new

PKCEのトークンリクエストはフロントエンドから?バックエンドから?

Tweet ThisSend to Facebook | by:nishino
 先日、こんな記事が出てました、いつものように「丁寧 & 上手くまとまっているなー。」なんて思いながら眺めていると、


  クライアント認証は Confidential Clientからで、Public Clientでは行わない。みたいな記述があり、これってPKCEの時はどうなんだっけか?と思いちょっと調べ直してみました。ちなみに、私は、PKCEの際も、バックエンドからクライアント認証付きでトークン・リクエストするモンだと思っています。

 ... で、何を参考にしようか?という話ですが、最近、某弊「汎用認証サイト」と著名なIdMaaSとをコンパチってみようと考えているので、Auth0をちょっと見てみました。


 こちらをみると、予想に反して、トークン・リクエストにはクライアント認証の認証ヘッダが指定されていないっぽいですね。「えー?」と思ってHybrid Flowを確認してみると、


 こちらは、client_secretを含むのでバックエンドにcodeをポストしてからの、バックエンドからのトークン・リクエストっぽいですね。

 そして、双方とも、client_id & client_secretを認証ヘッダへ指定する client_secret_basic ではなく、ポストするclient_secret_post っぽいです(ただし、PKCEの場合は、client_secretを指定せず)。

 ...と言う事で、一度、RFCを確認してみましょう。

  Upon receipt of the Authorization Code, the client sends the Access Token Request to the token endpoint. In addition to the parameters defined in the OAuth 2.0 Access Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter : code_verifier REQUIRED.

 ... とあるので、個人的には、通常通り、バックエンドからトークン・リクエストする際に、code_verifier パラメタを追加して投げるように見えるのですが、確かに行間があって、RFCの冒頭に、Public Clientでは、client_secretを持てないので ... 的な記述があるので、解釈次第と言うか、空気を読むと、フロントエンドから、クライアント認証なしで、code_verifierだけ追加して投げることもできように見えます(実際、初めは、私もそうだと思っていたのだけど、前述のRFCの文とHybrid Flowの仕様を見て、実装を書き直した)。

 一応、他の著名なIdMaaSを探してみると、


 Amazon Cognitoの方は、
  Authorization=Basic aSdxd892iujendek328uedj

 が入ってしまっていますが、Azure ADの方の仕様に、Public Clientの場合は、client_secretは指定しないと明記されているので、

 「Public Clientから使う場合は、client_secretを指定しなくても(クライアント認証しなくても)code_verifier さえ指定すればトークン・リクエストできるよ。」

 ... って話っぽいですね。うーん、... マンダム。これ ... RFC読んでないと、と言うか、RFC読んでいても仕様の解釈を間違う事があるぐらいなので、APIリファレンスだけだと仕様を正確に捉えることが難しいんじゃないかな?なんて思ったりしました。... と言う事で(、脆弱性があったと言う事ではなく、RFCと違っていたため)、次バージョンでは、ココを修正してリリース予定です。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告
12345