OAuth2.0を勉強しなければいけなくなったのだけれど、ちょっと調べてもよくわからない。日本語の記事を読んでも、たぶん自分には前提となる知識が抜けているのかいまいちわからない。

自分は原典厨なので、OAuth2.0についてのRFCを読んでそれをまとめることにした。メモ的な意味をかねてここに要約を書いた。

Abstract

OAuth2.0 authorization frameworkはサードパーティのアプリケーションに，HTTPサービスへの制限されたアクセス権を取得できるようにさせるための仕組みである．

1. Intorduction

従来のクライアント・サーバによる認証モデルでは，クライアントがサーバにリソースオーナの認証情報を用いて認証して，サーバに対して制限されたアクセス権をリクエストする．サードパーティのアプリケーションにリソースへのアクセスを提供するためには，リソースオーナがサードパーティアプリに対して認証情報を共有する必要があった．

サードパーティアプリケーションは，今後も使うためにリソースオーナの認証情報を保持することが求められる．これは典型的には平文のパスワードを保持する．
サーバは，パスワード固有のセキュリティ面での弱さがあるのにも関わらず，パスワード認証をサポートすることを求められる．
サードパーティアプリは，オーナのリソースに対して過剰に広いアクセス権を得ることになる．さらに，オーナはリソースの一部に対するアクセス制限をかけることもできない．
リソースオーナは個々のサードパーティアプリに対してアクセス権を取り消すことができない．そうするためには全てのサードパーティアプリのアクセス権を取り消し，サードパーティアプリのパスワードも変更しなくてはならない．
サードパーティアプリが侵害されると，エンドユーザのパスワードも侵害されそのパスワードによって保護されている全てのデータも侵害されてしまう．

OAuthは，authorization layerの導入とリソースオーナの役割とクライアントの役割を切り離すことでこれらの問題に取り組む． OAuthでは，クライアントはリソースオーナによって管理され・リソースサーバにホスティングされているリソースに対するアクセスを要求する．さらにクライアントはリソースオーナの認証情報とは異なる認証情報を発行してもらうことになる．

保護されたリソースにアクセスするためにリソースオーナの認証情報を利用する代わりに，クライアントはアクセストークン（特定のスコープ・有効期限・その他のアクセス属性が記された文字列）を取得する．アクセストークンは，認証サーバから，サードパーティクライアントに対して，リソースオーナの許可を得て，発行される．クライアントはアクセストークンを，リソースサーバに設定された保護されたリソースに対するアクセスにために用いる．

例えば，エンドユーザ（リソースオーナ）は，印刷サービス（クライアント）に，写真共有サービス（リソースサーバ）に保存されている保護された写真に対するアクセス権を，ユーザ名とパスワードを印刷サービスに共有することなく，許可することができる．代わりに，ユーザは写真共有サービスに信頼されているサーバ（認証サーバ）を直接認証し，印刷サービスに特定の委譲認証情報（アクセストークン）を発行する．

この詳細は，HTTPを用いるように設計されている． HTTPを使用しない任意のプロトコル上でのOAuthの利用は，範囲外とする．

OAuth1.0プロトコルは，informationalな文章として発行され，小さなアドホックコミュニティの成果物だった．本文章でのインターネット標準の仕様は，OAuth1.0の運用経験およびいくつかのユースケースの追加とより広いIEFTコミュニティから集められた拡張性の要求を基に設計されている．２つのバージョンはおそらくネットワーク上に共存してもよく，実装では両方をサポートしてもよいだろう．しかし，この文章で策定することで，新たな実装がOAuth2.0をサポートしていき，OAuth1.0に関しては現在運用されているもののみがサポートするようになることを意図している． OAuth2.0プロトコルは，OAuth1.0と実装面の細部はほとんど共有していない．そのためOAuth1.0で慣れ親しんだ実装者は，構造と詳細については何の仮定もせずにこの文章を読むべきである．

1.1 Roles

OAuthは4つの役割を定義している．

リソースオーナこのエンティティは，保護されたリソースに対するアクセス権を許可することができる．リソースオーナが人間である場合は，エンドユーザのことを指す．
リソースサーバ保護されたリソースをホスティングしているサーバ．このエンティティは，保護されたリソースに対するアクセストークンを利用したリクエストに対して，許可と応答を行う．
クライアントリソースオーナの代わりに，リソースオーナから許可を得て，保護されたリソースに対するリクエストを行うアプリケーション． "クライアント"という用語は，特定の実装の特徴を暗喩しているわけではない（例えば，アプリケーションはサーバで実行されていてもいいし，デスクチェアで実行されていてもいいし，他のデバイスで実行されていてもよい）．
認証サーバリソースオーナの認証・認可の取得が成功した後に，クライアントに対してアクセストークンを発行するサーバ．