RFC 6749
名称 : The OAuth 2.0 Authorization Framework
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. 導入
このやり方だと、第三者 (サードパーティ、third party) のアプリケーションにアクセス制限されたリソースへのアクセス権を与えるために、リソース所有者は資格情報を第三者に共有する必要がある
このやり方には、第三者がパスワードを利用するためにパスワードを平文で保存する必要があることなど、いくつも問題や制限がある
OAuth は、認可レイヤ (authorization layer) を導入し、クライアントの役割をリソース所有者の役割から分離することで、これらの問題に対処する OAuth が定義する 4 つの役割 (role)
リソース所有者 (resource owner): 保護されたリソースへのアクセスを許可する能力を持つ存在 (人の場合、エンドユーザー (end-user) と呼ばれる)
リソースサーバー (resource server): 制限されたリソースをホスティングするサーバー
クライアント (client): リソース所有者に代わり、その認可を得て保護されたリソース要求を行うアプリケーション
認可サーバー (authorization server): リソース所有者の認証を行い、認可を得た後、クライアントにアクセストークンを発行するサーバー
プロトコルの流れ
https://gyazo.com/b025e95431918f21d19e1f52d6a257f1
クライアントがリソース所有者から認可許可を取得する際には認可サーバーを仲介として使用することが推奨される
認可許可 (authorization grant) は、リソース所有者の認可を表す資格情報 (credential)
この仕様で定義される 4 つの許可種別 (grant type) か、拡張許可種別 (extension grant type) で表現される
認可許可種別 (authorization grant type) は、クライアントが認可を要求するのに使う方法と、認可サーバーがサポートする種別に依存する
クライアント登録 (Client Registration)
プロトコル開始の前にクライアントは認可サーバーに登録する
その方法はこの仕様では定められていない
クライアントを登録する際にクライアント開発者は次のことを行う必要がある:
クライアント タイプを指定
クライアント リダイレクト URI を提供
認可サーバーで必要なその他の情報 (アプリケーション名、Web サイト、説明、ロゴ イメージ、法的条件の承諾など) を含める
クライアントタイプ
confidential: 資格情報 (credential) の機密性を維持できるもの (サーバー上に資格情報を格納する場合など)
public: 機密性を維持できないもの (ブラウザ上で動くものなど)
クライアントプロフィール
Web アプリケーション
ユーザーエージェントベースのアプリケーション
ネイティブアプリ
認可サーバーはクライアント識別子 (Client Identifier) を発行する
クライアント認証
OAuth 2.0 プロトコルのエンドポイント
認可サーバーの 2 つのエンドポイント
Authorization endpoint
Token endpoint
1 つのクライアントのエンドポイント
Redirection endpoint