[10] クライアントcredentialsは、 OAuthクライアントを識別、認証するための credentials です。
[5] OAuth 1.0 では、認証された要求の作成に先立ってクライアントと鯖との間でクライアントcredentials を準備しておく必要があります >>3。
[24] OAuth 2.0 では、利用に先立ってクライアントは認可鯖に自身を登録することになっています >>20。 認可鯖は、登録されたクライアントにクライアント識別子を発行します。
[27] しかしその具体的な方法は、 OAuth 1.0 >>3 も OAuth 2.0 >>20 も仕様の範囲外としています。
[92] OAuth 2.0 の追加仕様である RFC 7591 >>90 と RFC 7592 >>91 では、 Web API によりクライアントの登録と管理を行わせるための方法が規定されています。
[26] OAuth 2.0 クライアントの登録においては、
クライアントの開発者が次の情報を提供しなければなりません >>21。
[48] OAuth 1.0 は未登録のクライアントの利用に言及していませんでした。 OAuth 2.0 は未登録のクライアントの利用を排除していませんが、 OAuth 2.0 仕様の範囲外ともしています >>20。
[69] Google は OAuth 1.0 時代に consumer key と consumer secret
を共に anonymous として oauth_signature_method=HMAC-SHA1
を使う >>68 ことで、未登録のクライアントの利用を認めていました。
[35] 更に OAuth 2.0 はクライアント型が機密のクライアントに対してトークンエンドポイントでクライアント認証を求めており、またクライアント型が公開のクライアントもクライアント認証することを認めています。従って認可鯖およびクライアントはそのための情報も保持する必要があります。
[36] 資源所有者合言葉credentialsは、他の承諾型よりも限定的に用いるべきだとされています。 従って認可鯖は、クライアントが資源所有者合言葉credentials を利用できるかどうかのフラグも保持する必要があります。
[67] OpenID Connect はクライアント登録のための API の規定を含んでいます。
[4] クライアントcredentialsは、 固有識別子と、 共有秘密 (クライアント共有秘密 >>9) か RSA鍵組 (RSA公開鍵とRSA秘密鍵) によって構成されます >>3。
[52] クライアント識別子は、認証された要求においてクライアントを識別するために
oauth_consumer_key 引数で使います。
[32] クライアント共有秘密は、 oauth_signature=HMAC-SHA1
や oauth_signature=PLAINTEXT で使います。
RSA鍵は、 oauth_sianature=RSA-SHA1 で使います。
[12] 共有秘密や RSA秘密鍵は、クライアントが秘密に保持しておく必要があります。 共有秘密は鯖も署名の計算のために保持しておく必要があります。
[13] クライアントがネイティブアプリケーションで実行ファイルが配布される場合のように、 クライアントcredentialsを攻撃者が入手できてしまう場合もあります。 鯖はクライアントの識別の検証にクライアントcredentialsだけでなく、 可能ならIPアドレスその他の要素も考慮するべきです。 >>11
[31] 認可鯖は、登録されたクライアントに対してクライアント識別子を発行します。 クライアント識別子は、クライアントが提供した登録情報を表す、 認可鯖について固有の文字列です。 >>20
[43] 使用できる文字は、client_id 引数の構文上の制約のため、
印字可能ASCII文字に限られます。
[22] クライアント識別子は、秘密ではありません。これ単独でクライアントの認証に使ってはなりません。 >>20
[23] クライアント識別子の長さは OAuth 仕様としては未定義となっています。 クライアントは仮定を置くべきではありません。 認可鯖は長さを文書化するべきです。 >>20
[81] SurveyMonkey は client_id を利用者名とし、
client_secret と api_key を鯖が発行した値としています >>80。
api_key は公開の値なので、広義のクライアント識別子を構成するものと言えますが、なぜ
client_id と2つ指定させているのかは不明です。
[87] GitHub は認可に関する問い合わせの API で
client_id と client_secret
を基本認証の利用者名と合言葉として使っています >>86。
[65] トークンエンドポイントでは、クライアント識別子と credentials を使ったクライアント認証が行われます。
[18] OAuth 2.0 承諾型としてのクライアントcredentialsは、 クライアントcredentials (やその他の形のクライアントの認証) を認可承諾として使うものです >>17, >>61。
[19] 本承諾型は、認可の適用範囲 (scope) がクライアントの制御下にある被保護資源に限定される時 (クライアントが資源所有者でもある時) や、 他の資源所有者の制御下にある被保護資源であっても認可鯖との間で (OAuth の仕様外の何らかの方法で) 事前の取り決めがある時に使うことができます >>17, >>61。
[62] 本承諾型は、クライアント型が機密の場合以外は使ってはなりません >>61。
[63] クライアントはまず認可鯖のトークンエンドポイントにアクセストークンの要求を送信します。 認可鯖はクライアント認証を行ってから、アクセストークンを発行します。 >>61
[72] Azure が実装しています >>71。事前に登録した ID と鍵の組を使うようです。
[74] Twitter が実装しています >>73。 consumer key と consumer secret を使うようです。
[78] reddit は「Application Only OAuth」として gran_type=client_credentials
と grant_type=https://oauth.reddit.com/grants/installed_client
を利用しています。前者は機密のクライアントとしてアクセスする場合に、
後者は公開のクライアントとしてアクセスする場合並びに
「ログアウト状態の利用者」としてアクセスする場合に使います。 >>77
[85] GitHub の基本認証を使って OAuth アクセストークンを取得する API
>>84 は本承諾型とよく似ていますが、基本認証により資源所有者の認証を行い、
payload body の client_id と client_secret
を使ってクライアントの認証を行うものとなっています。
トークンエンドポイントとは異なるエンドポイントで独自の引数を使う他、
応答の形式も本承諾型とは異なっています。
[70] Google の OAuth 1.0 の拡張である 2-legged OAuth を使うと、
Google Apps の (特定の利用者に限定せず)
ドメイン全体のアクセスを認めることができました。
本承諾型はこのような用途に使えるものと思われます。ただし Google
は現在 Google Apps のドメイン全体のアクセスには
urn:ietf:params:oauth:grant-type:jwt-bearer を使っているようです。
[83] foursquare は本承諾型のような用途で client_id
と client_secret を URL query に指定する方法を採用しています
>>82。
oauth_consumer_key 引数 (OAuth 1.0)[8] oauth_consumer_key は、認証された要求でクライアントcredentialsの識別子
(consumer key) を表す >>7 引数です。
client_id 引数 (OAuth 2.0)[49] client_id 引数は、
クライアント認証でクライアント識別子を表します >>34。
クライアント認証を行う場合、この引数は必須です >>34。
[40] この引数の値は、0個以上の印字可能ASCII文字の列です >>39。
[58] 認可エンドポイントで認可符号やアクセストークンを取得する場合、 この引数は指定しなければなりません >>57, >>60。 指定されない場合や非妥当な場合、資源所有者に誤りを知らせるべきです >>59。
[56] client_id 引数は認証しない場合でもトークンエンドポイントへの要求
>>55 で指定できる場合、指定しなければならない場合があります。
認可鯖は、トークンエンドポイントで適宜認証および検査しなければなりません。
client_secret 引数 (OAuth 2.0)[50] client_secret 引数は、
クライアント認証でクライアント秘密を表します >>34。
この引数は、値が空文字列なら省略できます >>34。
[42] この引数の値は、0個以上の印字可能ASCII文字の列です >>41。
[38] クライアントcredentialsは、平文で送信してはなりません >>37。
grant_type=client_credentials[64] OAuth 2.0 トークンエンドポイントの grant_type
引数の値 client_credentials >>41
は、クライアントcredentials承諾型を表します。
[44] クライアントが秘密の値を保持する場合、ソースコードであれバイナリであれ、 それが公開されていると、 (暗号化されていたとしても原理的には) クライアントを配布された第三者がその値を知ることができてしまいますから、 注意が必要です >>45, >>66。またクライアントに埋め込まれて配布される場合、 それを revoke することも (すべての利用者が使えなくなってしまうので) 難しくなり、好ましくありません >>66。
[46] OAuth 1.0 ではクライアントcredentialsが必須なので、 秘密の値が漏れることを承知の上でネイティブアプリケーションが配布されていたりします。 OAuth 2.0 はクライアント型を設け、公開のクライアントはクライアント認証を行わないことを認めています。
[47] また、クライアントの開発者ごとにcredentialsを発行するのではなく、 クライアントの利用者ごとに発行することでこれを回避する場合もあります。 その場合でも、環境によっては第三者 (によるアプリケーション) がクライアントのストレージなどにアクセスして秘密の値を入手することが可能かもしれず、注意が必要です >>45。
Somewhat like our existing "2-LO" flow for OAuth 1. Obtain an access token that represents not an end user, but the owner of the client/consumer:
$ curl -X POST -u "client_id:secret" \
https://bitbucket.org/site/oauth2/access_token \
-d grant_type=client_credentials