[2] 資源鯖は、 被保護資源をホストしている鯖のことで、 アクセストークンを使った被保護資源要求を受理し応答する能力のあるものです >>1。
[6] クライアントは、トークンcredentialsを得たら、 クライアントcredentialsとトークンcredentialsを使った認証された要求により、 資源所有者にかわって保護資源にアクセスすることができます >>7。
[4] 鯖は、資源所有者が認めた処理の範囲、期間その他の指定を記憶し、 トークンcredentialsを使った要求を処理する際にその制限を適用しなければなりません >>7。
[8] クライアントは、資源鯖にアクセストークンを示すことで、 被保護資源にアクセスします >>5。その具体的方法はアクセストークンのトークン型に依存しますが、 一般的にはHTTP認証を使います >>5。
[9] 資源鯖は、アクセストークンを検証し、 満期しておらず適用範囲 (scope) が要求されている資源をカバーしていることを確認しなければなりません。 その具体的方法や誤りの応答については OAuth 仕様の範囲外とされていますが、 一般的には何らかの資源鯖と認可鯖との協調が必要となります。 >>5
[10] 資源鯖は、アクセス要求が失敗した時にはクライアントに誤りを通知するべきです。 しかしその具体的方法は OAuth 仕様の範囲外とされています。 >>5
[11] 主として OAuth のアクセストークン認証に用いる認証方式は、
クライアントに誤りの状態符号を伝える仕組みを定義し、
OAuth 2.0 の誤りの状態符号ののIANA登録簿に登録された値
(の一部または全部) を使うことができるものとするべきです。
その引数名が必要なら、 error とするべきです。
OAuth が主用途でない認証方式も、 IANA登録簿の誤りの値を使うことができます。
いずれにせよ、 error_description 引数や
error_uri 引数も OAuth 本体と同じように使うことができます。
>>5
[3] OAuth 1.0 では認可鯖と資源鯖が鯖 (サービス提供者) と呼ばれ、区別されませんでしたが、OAuth 2.0 では別のものとなっています。