[20] 資源所有者合言葉credentials承諾型は、 資源所有者の合言葉をクライアントが直接受け取り、 これを認可鯖に渡すことでアクセストークンの交付を受ける承諾型です。
[21] 本承諾型は危険性が高いもので、やむを得ない場合を除き使うべきではないと考えられています。
[2] 資源所有者合言葉credentials承諾型は、 アクセストークンを得るために資源所有者の credentials (利用者名と合言葉) を直接認可承諾として使うものです。 >>1
[14] 本承諾型は合言葉を使う点、資源所有者がクライアントにそれを委ねなければならない点から、 特に危険性が大きいものです。 認可鯖は本承諾型で発行されるアクセストークンの適用範囲と寿命を十分検討するべきです。 認可鯖およびクライアントはできるだけ他の承諾型を使うべきです。 >>13
[16] なお資源所有者の合言葉を平文で送信してはなりません。
[17] 認可鯖は、合言葉の推測による攻撃を防がなければなりません。 生成されたトークンの場合、 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです。 そうでない末端利用者が扱うcredentialsの場合でも、 何らかの方法で保護しなければなりません。 >>18
[7] まず資源所有者がクライアントに credentials (利用者名と合言葉)を提供します >>5。 これをどのような形で行うかは、OAuth 仕様の範囲外 >>5 とされています。
[8] クライアントは資源所有者から受信した利用者名と合言葉を指定した要求を認可鯖のトークンエンドポイントに送信し、 アクセストークンを求めます >>5。
[9] 認可鯖のトークンエンドポイントはクライアント認証を行い資源所有者の credentials を検証し、アクセストークンを発行します >>5。 更新トークンの発行も禁止はされていません。しかし本フローの危険性を鑑み、 発行しない方がよいかもしれません >>19。
[10] クライアントは、アクセストークンを受信したらクライアントの credentials を破棄しなければなりません >>5。
[3] 本承諾型は、クライアントと資源所有者との間に高度な信頼がある場合 (例えばクライアントが当該装置の OS や高い特権を持つ応用である場合) で、他の承諾型が馴染まない場合に限って使うべきです >>1, >>5。 認可鯖は、本承諾型を有効にする際に特別に注意を払うべきであり、 他のフローが馴染まない場合に限って認めるべきです >>5。
[4] 本承諾型は資源所有者の credentials (利用者名と合言葉) を (普通は対話的なフォームにより) クライアントが直接知ることができる場合に適しています >>1, >>5。既に基本認証やダイジェスト認証に対応しているクライアントが OAuth に移行する時に、既に保存している credentials をアクセストークンに変換するためにも使うことができます >>5。いずれにせよ、 credentials は一旦アクセストークンを得たら不要となり、 以後保存する必要はありません >>1。
[25] Salesfoces など >>24, >>26, >>27 が実装しています。
grant_type=password[12] OAuth 2.0 トークンエンドポイントの grant_type
引数の値 password >>11 は、
資源所有者の credentials からアクセストークンを求める要求であることを表します。
[28] draft-dehora-farrell-oauth-accesstoken-creds-02 - OAuth Access Tokens using credentials ( 版) <https://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-02>
$ curl -X POST -u "client_id:secret" \
https://bitbucket.org/site/oauth2/access_token -d grant_type=password \
-d username={username} -d password={password}