• Authlete 2.0

クライアント認証における制約の厳密化

概要


Authlete 2.0 ではクライアントタイプおよびクライアント認証方式の設定値の検証がより厳密になり、Authlete 1.1では許容されていたリクエストを拒否するように変更されました。

変更点


具体的な変更点については、下記のとおりです。
Authlete 1.1
Authlete 2.0
設定値の扱い
クライアントタイプ、クライアント認証方式の設定値の如何に関わらず、トークンリクエスト時にクライアントシークレットが含まれていれば、その値の検証を行う。

トークン・エンドポイントにおいて、client_id が指定されていないリクエストでも、認可コードやリフレッシュトークンの値から client_id を導出し、動作する。
クライアントタイプ、クライアント認証方式の設定値によって振る舞いが異なる。
  • A. クライアントタイプが public の時
    • A.1. クライアント認証方式は NONE でなければとエラーとなる。
    • トークン・エンドポイントにおいて client_id が指定されていないとエラーとなる。また、client_secret 等の不必要なパラメーターが含まれていてもエラーとなる。
  • B. クライアントタイプが confidential の時
    •  B.1. クライアント認証方式は NONE 以外の値でなければとエラーとなる。
    • B.2. 各クライアント認証方式によって以下のような制約が課される。
      • クライアント認証方式が client_secret_basic の時、クライアントシークレットがリクエストの Authorization ヘッダーに含まれていなければエラーとなる。
      • クライアント認証方式が client_secret_post の時、クライアントシークレットがリクエストボディに含まれていなければエラーとなる。
デフォルト設定値
クライアントタイプ: 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?