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

概要


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

変更点

Authlete 1.1
Authlete 2.0
設定値の扱い
クライアントタイプ、クライアント認証方式の設定値の如何に関わらず、トークンリクエスト時にクライアントシークレットが含まれていれば、その値の検証を行う。
クライアントタイプ、クライアント認証方式の設定値によって振る舞いが異なる。
  • A. クライアントタイプが public の時
    • A.1. クライアント認証方式は NONE でなければとエラーとなる
  • 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 では許容されていたリクエストについては、エラーが返却されることになります。
How did we do with this article?