[29] OAuth 1.0 の規定に従い要求引数を追加した HTTP要求を、 認証された要求といいます。 認証された要求には OAuth 1.0 による要求URLと引数の署名が含まれており、 鯖は正しいクライアントによって生成された要求であるかを検証できます。
[48] OAuth 1.0 では、最初の資源所有者に認可を求めアクセストークンを得る手続きとそれ以後のアクセストークンを使って Web API にアクセスする段階の両方で認証された要求を使います。 稀に本来の OAuth 1.0 以外でも本方式を流用していることがあります。
[2] 認証された要求には、 クライアントを表すクライアントcredentialsと、 資源所有者を表すトークンcredentialsを含めます >>1。
[3] 認証された要求の作成に当たっては鯖の設定に関する事前の知識が必要です。 クライアントが鯖の要求する設定をどう発見するかは OAuth 仕様の範囲外とされています。 >>1
[7] 認証された要求は、HTTP要求に次のように引数を加えて作成します。
oauth_consumer_keyoauth_tokenoauth_signature_methodoauth_timestampoauth_signature_method=PLAINTEXT なら、
省略して構いません。 >>6oauth_nonceoauth_signature_method=PLAINTEXT なら、
省略して構いません。 >>6oauth_version1.0。
省略しても構いません。 >>6oauth_body_hashoauth_body_hash 参照。)oauth_signature の値を計算します。 >>6oauth_signature 引数を >>15 で選択した転送方式により要求に追加します。 >>6[42] oauth_signature_method=RSA-SHA1 では、
xoauth_signature_publickey 引数や
xoauth_public_key 引数も指定されることがあります。
[32] 一時credentials要求では、クライアントが鯖に認証された要求を送信しますが、 この時はクライアントcredentialsだけ使い、トークンcredentialsは指定しません >>31。
[5] トークン要求では、クライアントが鯖に認証された要求を送信しますが、 この時はクライアントcredentialsと共に (トークンcredentialsのかわりに) 一時credentialsを使います >>4。
[36] xAuth では oauth_token を使わず、
HMAC-SHA1 計算時のトークン共有秘密は空文字列とします
>>35。
[33] Google の 2-legged OAuth では、
oauth_token を使わず、代わりに
xoauth_requestor_id を使うことになっていました。
ただし xoauth_requestor_id は Authorization:
ヘッダーではなく、 URL query に指定します。 >>34
[38] Bitbucket や Mobage >>47 の 2-Legged OAuth では、
oauth_token とトークン秘密を使わないことで、
consumer として操作することを表すようです。
[44] mixi から外部アプリケーションサイトへの署名つき要求は、
oauth_token を使わず、 oauth_signature_method=RSA-SHA1
により公開鍵方式で署名しています >>43, >>45, >>46。
[19] 鯖は、認証された要求を受信したら、次のように妥当性検証しなければなりません。oauth_signature
で指定された値と比較します。 >>18HMAC-SHA1 や
RSA-SHA1 が使われていれば、
oauth_nonce, oauth_timestamp,
oauth_token の値 (あれば) の組み合わせについて、
以前クライアントが使ったものと一致していないことを確認します。 >>18oauth_token があれば、
クライアントの認可の範囲と状態を検証します。 >>18oauth_version があれば、値が 1.0
か確認します。 >>18
[41] oauth_body_hash 引数が適用される場合には、
独自に計算し、指定された値と比較します。あるいは禁止されている場合に
oauth_body_hash が指定されていないことを確認します。 >>39
oauth_body_hash も参照。[24] この検証に失敗した場合には、 適切な状態符号で応答を返すべきです。 payload body に拒絶の理由の詳細を含めて構いません。 >>18
[27] oauth_timestamp がある程度古ければ、
鯖は拒絶しても構いません。
[25] 未対応の引数、未対応の署名方式、引数の不足、
OAuth 引数の重複が見られる時は、 400
応答を返すべきです >>18。
[26] 非妥当なクライアントcredentials、
非妥当なトークンや満期したトークン、
非妥当な署名、
非妥当な nonce や使用済みの nonce の時は、
401 応答を返すべきです >>18。
[37] OAuth 1.0 本体仕様としてはエラー時の応答についてこれ以上の詳細は規定していません。 OAuth Problem Reporting Extension は報告方法を規定しており、 実装によってはこれに対応しています。