OAuth
OAuth 2.0のプロトコルフローは以下のとおりである:
(A) まずクライアントがリソースオーナーに認可要求(Authorization Request)を出す。図ではクライアントがリソースオーナーに直接要求を出しているが、認可サーバー経由で間接的に要求する事がのぞましい.
(B) リソースオーナーは認可要求を許諾する旨の返答として認可グラントをクライアントに送る。これも認可サーバー経由で行う事がのぞましい
(C) クライアントは認可サーバーに認可グラントを送ることでアクセストークンを要求
(D) 認可サーバーはクライアントの認証と認可グラントの正当性の検証を行い、問題なければアクセストークンを発行。
(E)クライアントはアクセストークンにより認証を受けることで、保護されたリソースへのアクセスをリクエスト
(F) アクセストークンが正当なら、クライアントのリクエストを受け入れる
認可グラントにはその発行の方法に以下の4タイプがある:
認可コード:クライアントはリソースオーナーを認可サーバにリダイレクトし、認可サーバはリソースオーナーを認証した上で認可コード型の認可グラントを発行する。
インプリシット:スクリプト言語を使用してブラウザ上で実行されるクライアント向けに認可コードを最適化したもの
リソースオーナーパスワードクレデンシャル:ユーザ名とパスワードのペアのような、リソースサーバーへのフルアクセスを許す情報をリソースオーナーパスワードクレデンシャルと呼び、この情報を直接アクセストークンとして得る。
クライアントクレデンシャル:認可範囲がクライアントの管理下にある保護されたリソース, もしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合に用いる。
OAuth 2.0は次世代のOAuthプロトコルであり、OAuth 1.0とは後方互換性を持たない。OAuth 2.0はクライアントとなるウェブアプリケーション、デスクトップアプリケーション、スマートフォン、リビングデバイス等のアプリケーションの開発者に対し、リソースアクセス権限を付与する簡単な方法を提供する。この規格は開発途上である。 Eran Hammer-Lahavによれば、IETF OAuthワークグループは2010年終わりごろまでの範囲での締結を期待していたが作業は大幅に遅延し、2012年8月にようやくRFCエディタへ送付された。 仕様は中心になる The OAuth 2.0 Authorization Framework の他、など幾つかに分割されている。
facebookの新しいGraph APIはOAuth 2.0 Draft 10 のみをサポートし、OAuth 2.0 としては最大の実装の一つである。 2011年現在、Google およびマイクロソフトは OAuth 2.0による実験的なAPIを提供している。