[20] 資源所有者合言葉credentials承諾型は、
資源所有者の合言葉をクライアントが直接受け取り、
これを認可鯖に渡すことでアクセストークンの交付を受ける承諾型です。
[21] 本承諾型は危険性が高いもので、やむを得ない場合を除き使うべきではないと考えられています。
仕様書
- [1] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-1.3.3
- [5] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-4.3
- [11] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-4.3.2
- [13] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-10.7
- [15] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-10.8
- [18] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-10.10
- [19] RFC 6819 - OAuth 2.0 Threat Model and Security Considerations ( 版) http://tools.ietf.org/html/rfc6819#section-4.4.3
意味
[2] 資源所有者合言葉credentials承諾型は、
アクセストークンを得るために資源所有者の credentials
(利用者名と合言葉)
を直接認可承諾として使うものです。 >>1
[6] 認可符号フローや暗示的承諾型フローとは違って、クライアントが資源所有者の
credentials を一旦取得する必要があります。[14] 本承諾型は合言葉を使う点、資源所有者がクライアントにそれを委ねなければならない点から、
特に危険性が大きいものです。
認可鯖は本承諾型で発行されるアクセストークンの適用範囲と寿命を十分検討するべきです。
認可鯖およびクライアントはできるだけ他の承諾型を使うべきです。 >>13
[22] 認可鯖はクライアントが資源所有者に対して明確に説明しているかどうかを一切関知できません。
他のフローでは認可鯖が資源所有者に対して行うような適用範囲の説明も、
本承諾型では機会がありません。例えばクライアントが読み取りのみ行うと説明しつつ、
実際には読み書きの両方が可能な適用範囲を認可鯖に求めることもあり得ます。[23] ですから認可鯖は、他の手段、例えば電子メールによる通知で、
事後であっても資源所有者に何が行われたか説明する必要があるかもしれません。[16] なお資源所有者の合言葉を平文で送信してはなりません。
[17] 認可鯖は、合言葉の推測による攻撃を防がなければなりません。
生成されたトークンの場合、
攻撃者が推測できる確率は 2-128 以下でなければならず、
2-160 以下であるべきです。
そうでない末端利用者が扱うcredentialsの場合でも、
何らかの方法で保護しなければなりません。 >>18
フロー
[7] まず資源所有者がクライアントに credentials
(利用者名と合言葉)を提供します >>5。
これをどのような形で行うかは、OAuth 仕様の範囲外 >>5 とされています。
[8] クライアントは資源所有者から受信した利用者名と合言葉を指定した要求を認可鯖のトークンエンドポイントに送信し、
アクセストークンを求めます >>5。
[9] 認可鯖のトークンエンドポイントはクライアント認証を行い資源所有者の
credentials を検証し、アクセストークンを発行します >>5。
更新トークンの発行も禁止はされていません。しかし本フローの危険性を鑑み、
発行しない方がよいかもしれません >>19。
[10] クライアントは、アクセストークンを受信したらクライアントの
credentials を破棄しなければなりません >>5。
- R
- 資源所有者
- C
- クライアント
- S
- 認可鯖
- R -> C
- 資源所有者の credentials を提供
- C -> S
- トークンエンドポイントに credentials を送信
- S -> C
- アクセストークンを発行
- #C#
- credentials を破棄
文脈
[3] 本承諾型は、クライアントと資源所有者との間に高度な信頼がある場合
(例えばクライアントが当該装置の OS や高い特権を持つ応用である場合)
で、他の承諾型が馴染まない場合に限って使うべきです >>1, >>5。
認可鯖は、本承諾型を有効にする際に特別に注意を払うべきであり、
他のフローが馴染まない場合に限って認めるべきです >>5。
[4] 本承諾型は資源所有者の credentials (利用者名と合言葉)
を (普通は対話的なフォームにより) クライアントが直接知ることができる場合に適しています
>>1, >>5。既に基本認証やダイジェスト認証に対応しているクライアントが
OAuth に移行する時に、既に保存している credentials をアクセストークンに変換するためにも使うことができます
>>5。いずれにせよ、 credentials は一旦アクセストークンを得たら不要となり、
以後保存する必要はありません >>1。
[25] Salesfoces など >>24, >>26, >>27 が実装しています。
- [24] Understanding the Username-Password OAuth Authentication Flow ( 版) https://www.salesforce.com/us/developer/docs/api_rest/Content/intro_understanding_username_password_oauth_flow.htm
- [26] Bitly API Documentation ( 版) http://dev.bitly.com/authentication.html
- [27] gitlabhq/oauth2.md at master · gitlabhq/gitlabhq ( 版) https://github.com/gitlabhq/gitlabhq/blob/master/doc/api/oauth2.md
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
[29] Bitbucket API
()
https://developer.atlassian.com/bitbucket/api/2/reference/meta/authentication$ curl -X POST -u "client_id:secret" \
https://bitbucket.org/site/oauth2/access_token -d grant_type=password \
-d username={username} -d password={password}