RFC6749
The OAuth 2.0 Authorization Framework
1. はじめに
例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える. OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない. そのかわり, 彼女は写真共有サービスの信任を得たサービス (認可サーバー) に対して認証を行い, 印刷サービスへのアクセス権限委譲用クレデンシャル (アクセストークン) を発行させる.
1.1. 登場人物
リソースオーナー (resource owner)
リソースサーバー (resource server)
クライアント (client)
認可サーバー (authorization server)
1.3. 認可グラント
認可コード
インプリシット
リソースオーナーパスワードクレデンシャル
クライアントクレデンシャル
2.1. クライアントタイプ
コンフィデンシャル(サーバ上のアプリケーションとか)
パブリック(ブラウザ上のアプリケーションとかスマホのネイティブアプリとか)
2.3.1. クライアントパスワード
例
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
パスワード認証を行う場合, 認可サーバーはSection 1.6にある通りTLSの利用を必須としなければならない (MUST).
クライアント認証方式にパスワードが含まれるので, 認可サーバーはクライアント認証を行うすべてのエンドポイントでブルートフォースアタック対策を行わなくてはならない (MUST).
3. プロトコルエンドポイント
認可サーバー
認可エンドポイント
トークンエンドポイント
クライアント
リダイレクトエンドポイント