意味
[24] OAuth 1.0 資源所有者は、
credentials を使って鯖と認証することにより被保護資源をアクセス、
制御する能力のある実体です >>1。
[2] 元々は資源所有者のことを利用者ともいいました >>1。[23] OAuth 2.0 資源所有者は、
被保護資源へのアクセスを承諾する能力のある実体です。
資源所有者が人間の時は、末端利用者を指します。 >>22
[3] 資源所有者は、鯖において自身を識別する何らかの方法
(鯖の提供するサービス上のアカウント) を有しているのが普通です。
その認証に使う合言葉などの credentials を鯖と資源所有者の間で事前に共有しているのが普通です。
[7] その具体的な仕組みや形式は OAuth の仕様の範囲外であり、
鯖が自由に決定できます。多くのWebサービスでは、
最初に資源所有者が登録した利用者名ないし電子メールアドレスと合言葉との組を使ってログインし、
セッションクッキーを発行して以後はCookie認証を用いる形を採っています。
その他 HTTP 基本認証などを使うこともできます。[5] OAuth 1.0 や多くの OAuth 2.0 認可承諾フローでは、
資源所有者の credentials をクライアントに伝える必要はありません。
これが OAuth の大きな特徴の一つとされています。
[6] OAuth 2.0 資源所有者合言葉credentialsフローでは、
資源所有者の credentials を一旦クライアントに伝える必要があります。
クライアントはアクセストークンを取得したらその credentials
を破棄することになっています。
[8] 本方式を使う場合、鯖は資源所有者の利用者名と合言葉の組を登録または発行しておく必要があります。
これは当該 Webサービスの通常のログイン時に用いるものであっても構いませんし、
OAuth 専用のものであっても構いません。 (どちらにするかは当該
Webサービスの性質やセキュリティーの方針によるでしょう。)[10] トークンエンドポイントの username 引数と
password 引数は、資源所有者合言葉passwordフローの要求において、
それぞれ資源所有者の利用者名と合言葉を指定しなければなりません
>>9。
トークンエンドポイントを参照。[12] username と password の値は、
0文字以上の Unicode 符号位置の列です。ただし、
U+0009 を除くC0制御文字、U+007F、
サロゲート、U+FFFE、U+FFFF
は禁止されています。 >>11