先日、こんな記事が出てました、いつものように「丁寧 ＆ 上手くまとまっているなー。」なんて思いながら眺めていると、


　 クライアント認証は 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を確認してみましょう。


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

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


　Amazon Cognitoの方は、
　　Authorization=Basic aSdxd892iujendek328uedj

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


　... って話っぽいですね。うーん、... マンダム。これ ... RFC読んでないと、と言うか、RFC読んでいても仕様の解釈を間違う事があるぐらいなので、APIリファレンスだけだと仕様を正確に捉えることが難しいんじゃないかな？なんて思ったりしました。... と言う事で（、脆弱性があったと言う事ではなく、RFCと違っていたため）、次バージョンでは、ココを修正してリリース予定です。