[2] OAuth 2.0 のクライアント認証は、クライアント (Web API にアクセスする外部サービス) に関して認可サーバーが認証するものです。
[43] クライアント型が機密のクライアントと、 クライアントcredentialsを発行されたクライアントは、 トークンエンドポイントへの要求でクライアント認証を行わなければなりません >>34, >>52, >>61, >>65, >>1。 ただしネイティブアプリケーションは、 認可符号フローにおいてクライアントの credentials を送信するべきではありません >>21。
[49] クライアント型が公開のクライアントは、(以上に該当しなくても)
トークンエンドポイントへの要求で自身を識別する
client_id 引数を使っても構いません >>34, >>97。
[98] なおこのクライアント認証は、トークンエンドポイントの他、 revokeエンドポイントでも使われます。
[82] 認可鯖は、クライアント型が機密のクライアントやクライアントcredentials を発行したクライアントに関しては、 トークンエンドポイントにおける OAuth 2.0 の各承諾型の要求において、 クライアント認証を必須としなければなりません >>52, >>61, >>65, >>1, >>89。
[22] 認可鯖は、クライアント型が機密のクライアントについては、 自身の要件次第で任意の認証方式を使って認証して構いません >>201。 認可鯖は、クライアント型が公開のクライアントについても認証して構いませんが、 クライアントの識別のためにこれに依存してはなりません >>201。
[25] 認可鯖は、 トークンエンドポイントにおける OAuth 2.0 の各承諾型の要求にクライアント認証が含まれていれば、認証しなければなりません >>52, >>61, >>65, >>1。
[3] 具体的な方式は、認可サーバーが決めることができます。複数の方法を提供する場合は、 その中からクライアントが選択できます。
[26] 複数の認証方法を単独の要求で併用してはなりません >>201。
[110] OAuth 2.0 本体は認証方式に特に名前を与えていませんが、 RFC 7591 >>8 や OpenID Connect は名前を定義 >>109 しています。 RFC 7591 はIANA登録簿を規定しているので、いくつかは IANA登録簿 >>7 に登録されています。次の認証方式があります。
[27] 認可鯖は、合言葉で認証する時は、 TLS を要求しなければなりません >>201, >>89。また総当たり攻撃に対してエンドポイントを保護しなければなりません >>201。
[60] 認可鯖は基本認証以外のHTTP認証方式に対応しても構いませんが、 クライアント識別子と当該認証方式との対応関係を定義しなければなりません >>201。
[90] 認可鯖は、Webアプリケーションたるクライアントに関して合言葉よりも強い認証手段を検討することが推奨されています。 Webアプリケーションは合言葉その他の credentials の機密性を維持しなければなりません。 >>89
none[28] 合言葉を使う場合、基本認証を使って構いません。 クライアントに合言葉を発行した認可鯖は、基本認証に対応しなければなりません。 >>201
client_id および client_secret
の指定によってアクセストークンを取得する独自のフローを実装しており >>172、
その場合基本認証は資源所有者の利用者名と合言葉になります。grant_type=password で資源所有者合言葉credentials
フローを装っていますが、クライアントの認証を引数によって行い、
資源所有者の認証を基本認証によって行う >>190 としており、
OAuth 2.0 とは異なっています。client_secret_basic[29] 基本認証を使う場合、利用者名はクライアント識別子を UTF-8 で
application/x-www-form-urlencoded 符号化したもの、
合言葉はクライアントの合言葉を UTF-8 で
application/x-www-form-urlencoded 符号化したものとします。
>>201 これを client_secret_basic と呼びます >>109, >>8。
client_secret_post[33] 認可鯖は、 payload body に引数を指定する方式に対応しても構いません。
しかしクライアントは基本認証を使えない場合のみこの方法を使うべきです。
payload body でなく要求URL中で指定してはなりません。 >>201
これを client_secret_post と呼びます >>109, >>8。
[59] その場合、クライアントは client_id 引数にクライアント識別子を、
client_secret 引数にクライアント秘密を指定しなければなりません。
ただしクライアント秘密が空文字列なら、 client_secret
引数は省略できます。 >>201
[112] OpenID Connect は JWT 形式で client_assertion
引数と client_assertion_type 引数を指定するクライアント認証方式を
client_secret_jwt, private_key_jwt
の2通り規定しています。
[5] RFC 7521 は client_assertion
引数と client_assertion_type 引数と省略可能な
client_id 引数を使った assertion
によるクライアント認証方式 >>4 を規定しています。
[81] 認可鯖は、ネイティブアプリケーションや利用者エージェントベースのアプリケーションであるクライアントにクライアント認証用の合言葉その他の credentials を発行してはなりません。ただしネイティブアプリケーションを特定の装置上で動作させたものに対しては合言葉その他の credentials を発行しても構いません。 >>89
[94] 認可鯖は、推測による攻撃を防がなければなりません。 生成されたトークンの場合、 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです。 そうでない末端利用者が扱うcredentialsの場合でも、 何らかの方法で保護しなければなりません。 >>89
[91] 認可鯖は、クライアント認証が不可能な時に、 クライアントの identity を検証する他の手段を用いるべきです。 例えば、リダイレクトURLを登録させたり、資源所有者に協力させたりできます。 認可鯖は、性質上認証できないクライアントについてはリダイレクトURL の登録を求めなければなりません。それ以外でも不正なクライアントから資源所有者を保護する方策をとるべきです。 リダイレクトURLが正しいからといってクライアントの identity の検証には不十分ではありますが、 credentials を不正なクライアントに渡してしまうことは防止できます。 >>89
[92] 認可鯖は認証していないクライアントとのやりとりのセキュリティーを勘案し、 更新トークンなど他の credentials を渡さないなど注意しなければなりません >>89。
[103] 本項のクライアント認証は、 SSLクライアント認証とは関係ありません。