クライアント認証における制約の厳密化
概要
Authlete 2.0 以降ではクライアントタイプおよびクライアント認証方式の設定値の検証がより厳密になり、Authlete 1.1では許容されていたリクエストを拒否するように変更されました。
変更点
具体的な変更点は下記の通りです。
Authlete 1.1 |
Authlete 2.0 以降 |
|
設定値の扱い |
クライアントタイプ、クライアント認証方式の設定値の如何に関わらず、トークンリクエスト時にクライアントシークレットが含まれていれば、その値を検証する。 トークンエンドポイントにおいて、client_id が指定されていないリクエストでも、認可コードやリフレッシュトークンの値から client_id を導出し動作する。 |
クライアントタイプ、クライアント認証方式の設定値によって振る舞いが異なる。
|
デフォルト設定値 |
クライアントタイプ: public クライアント認証方式: client_secret_basic |
クライアントタイプ: public クライアント認証方式: none |
Authlete 1.1 から 2.0 への移行時の注意点
Authlete 1.1 では、設定されたクライアント認証方式が client_secret_basic であったとしても、トークンリクエストのリクエストボディにクライアントシークレットが埋め込まれていた場合には、その値を検証します。
一方 Authlete 2.0 では、client_secret_basic として設定されている場合には Authorization ヘッダーにクライアントシークレットが含まれていることが必須となります。したがって上記のような、Authlete 1.1 では許容されていたリクエストについては、エラーが返却されることになります。
具体的には、下記のポイントに注意の上、設定を変更してください。
クライアントがパブリッククライアントの場合
- サービス側の設定にて、サポートするクライアント認証方式に「NONE」が含まれていることを確認する。
- クライアント側の設定にて、 クライアント認証方式が「NONE」になっていることを確認する。
- クライアントからのトークンリクエスト中に client_id が含まれていることを確認する。
クライアントがコンフィデンシャルクライアントの場合
- サービス側の設定にて、サポートするクライアント認証方式が正しく設定されていることを確認する。
- クライアント側の設定にて、クライアント認証方式が正しく設定されていることを確認する。
- Authlete の /auth/token API をコールする際に、適切なパラメーターが設定されていることを確認する。
How did we do with this article?