クライアント認証

クライアント認証 (OAuth 2.0)

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

認証方式 client_secret_basic

[29] 基本認証を使う場合、利用者名クライアント識別子UTF-8application/x-www-form-urlencoded 符号化したもの、 合言葉クライアント合言葉UTF-8application/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 ConnectJWT 形式で client_assertion 引数client_assertion_type 引数を指定するクライアント認証方式を client_secret_jwt, private_key_jwt の2通り規定しています。

[5] RFC 7521client_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

実装

関連

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

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