[2] OAuth 2.0 のクライアント認証client authenticationは、クライアント (Web API にアクセスする外部サービス) に関して認可サーバーが認証するものです。

仕様書

文脈

[43] クライアント型が機密のクライアントと、 クライアントcredentialsを発行されたクライアントは、 トークンエンドポイントへの要求でクライアント認証を行わなければなりません >>34, >>52, >>61, >>65, >>1。 ただしネイティブアプリケーションは、 認可符号フローにおいてクライアントの credentials を送信するべきではありません >>21。

[49] クライアント型が公開のクライアントは、(以上に該当しなくても) トークンエンドポイントへの要求で自身を識別する client_id 引数を使っても構いません >>34, >>97。

この場合は credentials は指定しないので、クライアント認証は行われません。

[98] なおこのクライアント認証は、トークンエンドポイントの他、 revokeエンドポイントでも使われます。

処理

[82] 認可鯖は、クライアント型が機密のクライアントやクライアントcredentials を発行したクライアントに関しては、 トークンエンドポイントにおける OAuth 2.0 の各承諾型の要求において、 クライアント認証を必須としなければなりません >>52, >>61, >>65, >>1, >>89。

[22] 認可鯖は、クライアント型が機密のクライアントについては、 自身の要件次第で任意の認証方式を使って認証して構いません >>201。 認可鯖は、クライアント型が公開のクライアントについても認証して構いませんが、 クライアントの識別のためにこれに依存してはなりません >>201。

[24] 一般的には合言葉や、公開鍵と秘密鍵の組のようなものを認可鯖が発行または登録して使います >>201。クライアントの登録も参照。

[25] 認可鯖は、 トークンエンドポイントにおける OAuth 2.0 の各承諾型の要求にクライアント認証が含まれていれば、認証しなければなりません >>52, >>61, >>65, >>1。

[23] OAuth 2.0クライアント認証はクライアントと認可鯖の間の任意のエンドポイントで利用可能な形で規定されてはいますが、実際に利用されるのはトークンエンドポイントでのみです。

認証方式

[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アプリケーションたるクライアントに関して合言葉よりも強い認証手段を検討することが推奨encourageされています。 Webアプリケーションは合言葉その他の credentials の機密性を維持しなければなりません。 >>89

認証方式 none

[111] none は、クライアント認証なしを表します >>109, >>8。

合言葉に基づく認証方式

[28] 合言葉passwordを使う場合、基本認証を使って構いません。 クライアントに合言葉を発行した認可鯖は、基本認証に対応しなければなりません。 >>201

[118] Google と Facebook >>164、 GitHub >>166 その他いくつかのサービス >>119, >>133, >>142, >>147, >>159, >>163, >>185 は、少なくてもドキュメントに明記されている範囲では、 引数を使う方法のみ対応していて、基本認証には対応していないようです。[130] Twitter など >>129, >>144, >>175, >>181, >>6 は基本認証にのみ対応しているようです。[141] Spotify は基本認証を原則とし、引数を使う方法にも対応しています >>140。 Amazon は引数を使う方法を原則とし、基本認証にも対応しています >>180。[174] Bitly は認可符号フローにおいては引数を使う方法のみ記載し、 資源所有者合言葉credentialsフローにおいては基本認証のみ記載しています >>172。 なお Bitly はトークンエンドポイントにおいて基本認証のみ、 または基本認証と client_id および client_secret の指定によってアクセストークンを取得する独自のフローを実装しており >>172、 その場合基本認証は資源所有者の利用者名と合言葉になります。[191] Ci は grant_type=password で資源所有者合言葉credentials フローを装っていますが、クライアントの認証を引数によって行い、 資源所有者の認証を基本認証によって行う >>190 としており、 OAuth 2.0 とは異なっています。[155] Salesforce は引数を使う方法と、 JWT を使う方法に対応しています >>154, >>153。

認証方式 client_secret_basic

[29] 基本認証を使う場合、利用者名はクライアント識別子を UTF-8 で application/x-www-form-urlencoded 符号化したもの、 合言葉はクライアントの合言葉を UTF-8 で application/x-www-form-urlencoded 符号化したものとします。 >>201 これを client_secret_basic と呼びます >>109, >>8。

[30] 入力が名前と値の組でないわけですが、 application/x-www-form-urlencoded 版パーセント符号化を使うという意味だと思われます。

[31] なぜか認可鯖側の解釈の方法は規定されていません。

[32] どの文字がパーセント符号化されるのか RFC および参照先の HTML4 では曖昧なので、鯖は一旦復号してから比較する必要がありそうです。

認証方式 client_secret_post

[33] 認可鯖は、 payload body に引数を指定する方式に対応しても構いません。 しかしクライアントは基本認証を使えない場合のみこの方法を使うべきです。 payload body でなく要求URL中で指定してはなりません。 >>201 これを client_secret_post と呼びます >>109, >>8。

[59] その場合、クライアントは client_id 引数にクライアント識別子を、 client_secret 引数にクライアント秘密client secretを指定しなければなりません。 ただしクライアント秘密が空文字列なら、 client_secret 引数は省略できます。 >>201

[57] client_secret 引数の構文上の制約により、 この方法を使うなら合言葉に含められるのは印字可能ASCII文字に限られます。

assertion に基づく認証方式

[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 を規定しています。

クライアント認証 credentials に関する要件

[81] 認可鯖は、ネイティブアプリケーションや利用者エージェントベースのアプリケーションであるクライアントにクライアント認証用の合言葉その他の credentials を発行してはなりません。ただしネイティブアプリケーションを特定の装置上で動作させたものに対しては合言葉その他の credentials を発行しても構いません。 >>89

[94] 認可鯖は、推測による攻撃を防がなければなりません。 生成されたトークンの場合、 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです。 そうでない末端利用者が扱うcredentialsの場合でも、 何らかの方法で保護しなければなりません。 >>89

[91] 認可鯖は、クライアント認証が不可能な時に、 クライアントの identity を検証validateする他の手段を用いるべきです。 例えば、リダイレクトURLを登録させたり、資源所有者に協力させたりできます。 認可鯖は、性質上認証できないクライアントについてはリダイレクトURL の登録を求めなければなりません。それ以外でも不正なクライアントから資源所有者を保護する方策をとるべきです。 リダイレクトURLが正しいからといってクライアントの identity の検証には不十分ではありますが、 credentials を不正なクライアントに渡してしまうことは防止できます。 >>89

[92] 認可鯖は認証していないクライアントとのやりとりのセキュリティーを勘案し、 更新トークンなど他の credentials を渡さないなど注意しなければなりません >>89。

[44] 認可鯖はクライアント認証を次の目的で使います >>34。
  • [45] 更新トークンや認可符号とその発行先のクライアントとの紐付け。 認可符号を安全でない通信路でリダイレクトエンドポイントに送る時やリダイレクトURL が完全に登録されていない時には特に重要です。
  • [46] クライアントを無効化したり、credentials を変更したりして、 更新トークンが漏洩した時に濫用を防止。更新トークンをすべて変更するよりはこちらの方が容易です。
  • [47] credentials の定期的な入れ替えrotationを含む認証管理で良いとされている慣習の実行。 更新トークンをすべて入れ替えるのは大変ですが、クライアントcredentials一式だけならずっと容易です。
[93] 認可エンドポイントも参照。

実装

関連

[103] 本項のクライアント認証は、 SSLクライアント認証とは関係ありません。

[300] 理論上は TLSクライアント認証を OAuth 2.0クライアント認証の実現方式として採用することもできますが...