RFC6749を読んでOAuth 2.0を理解する

<h2>情報源</h2>
<p>The OAuth 2.0 Authorization Framework</p>
<ul>
<li><a href="https://datatracker.ietf.org/doc/html/rfc6749#page-15" target="_blank" rel="nofollow noopener noreferrer">https://datatracker.ietf.org/doc/html/rfc6749#page-15</a></li>
</ul>
<h2>まとめ</h2>
<ul>
<li>OAuth 2.0はサードパーティアプリケーションがHTTPサービスへの制限付きのアクセスを可能にするためのフレームワークである。</li>
<li>リソースオーナーとHTTPサービスの間の認証を行うことによってリソースオーナーに代わって、サードパーティーアプリケーションがリソースにアクセスする。</li>
</ul>
<h3>イントロダクション</h3>
<ul>
<li>
<p>従来のclient-server間の認証モデルではクライアントがサーバー上のアクセス制限されたリソース（保護されたリソース）を要求し、そのサーバーはリソースオーナーの信用情報を使用して認証をおこなっていた。</p>
</li>
<li>
<p>制限されたリソースに対するサードパーティアプリケーションのアクセスを提供するために、リソースオーナーはサードパーティにその信用情報を共有する必要があった。これはいくつかの問題と制限を生んでいた。</p>
</li>
<li>
<p>サードパーティアプリケーションはあとで使用するためにリソースオーナーの信用情報を要求される。典型的にはパスワードなど。</p>
</li>
<li>
<p>サーバーはパスワードには潜在的にセキュリティ的に問題があるにもかかわらずパスワード認証をサポートすることを要求される。</p>
</li>
<li>
<p>サードパーティアプリケーションはリソースオーナーの保護されたリソースに対する過剰なアクセスを手に入れる。リソースオーナーが期間を制限しなかったり、リソースへのアクセス制限をしないままにしたとき。</p>
</li>
<li>
<p>リソースオーナーは個別のサードパーティに対するアクセスをrevokeできない。全てのサードパーティへのアクセスをrevokeするのでサードバーティのパスワードを変更しなければならない。</p>
</li>
<li>
<p>全てのサードバーティアプリケーションのパスワードの妥協はエンドユーザーのパスワードの妥協になり、そのパスワードによってデータが保護されることになる。</p>
</li>
<li>
<p>OAuthはこれらの問題に認可レイヤを導入し、リソースオーナーからクライアントの役割を分離した。</p>
</li>
<li>
<p>OAuthではクライアントはサーバーによってホストされリソースオーナーによって制御されたリソースへのアクセスを要求する。</p>
</li>
<li>
<p>リソースオーナーの信用情報を使って保護されたリソースへアクセスする代わりにクライアントはアクセストークンを手に入れる。</p>
</li>
<li>
<p>アクセストークンとは特定のスコープ、ライフタイムやその他アクセス属性をもつ文字列である。</p>
</li>
<li>
<p>アクセストークンはリソースオーナーの承認を利用して認証サーバーによってサードパーティークライアントに対して発行される。</p>
</li>
<li>
<p>例えばリソースオーナーであるエンドユーザーはクライアントであるプリントサービスが彼の写真共有サービス（リソースサーバー）にある写真へのアクセスすることを承認できる。このときプリントサービスで使用されるユーザーネームやパスワードは必要がない。</p>
</li>
<li>
<p>代わりにユーザーは直接写真共有サービス（認証サーバー）によって信頼されているサーバーを使用して認証する。認証サーバーはプリントサービスに対して限定的な信用情報の委譲（アクセストークン）を発行する。</p>
</li>
<li>
<p>この仕様書はHTTPを使用することを想定している。</p>
</li>
<li>
<p>HTTP以外のプロトコルによってOAuthを使用することはこの仕様書のスコープ外である。</p>
</li>
<li>
<p>OAuth 2.0はOAuth 1.0に対する後方互換性を持たない。</p>
</li>
<li>
<p>OAuth 2.0とOAuth 1.0は共存して良いが新しく開発するときにはOAuth 2.0を使用することを意図している。</p>
</li>
<li>
<p>OAuth 2.0はOAuth 1.0と実装の詳細がほぼ異なる。</p>
</li>
</ul>
<h3>1.1 役割</h3>
<ul>
<li>OAuthでは4つの役割を定義している。</li>
<li>resource ownerは保護されたリソースへのアクセスを承認することが可能な実体である。resource ownerが人間の場合はエンドユーザーと呼ばれる。</li>
<li>resource serverは保護されたリソースをホストしているサーバーであり、アクセストークンを使用した保護されたリソースのリクエストを受け入れたり、それに応答したりすることができる。</li>
<li>clientは認証を使ってリソースオーナーに代わって保護されたリソースへの要求を作成するアプリケーションである。「クライアント」は特定の実装を指すものではなく、サーバーで実行されても良いし、デスクトップで実行されても良い。</li>
<li>authorization serverはクライアントがリソースオーナーを認証して、認証を得ることに成功した後にクライアントに対してアクセストークンを発行するサーバーである。</li>
<li>認証サーバーとリソースサーバーのやり取りはこの仕様書の範疇を超えている。認証サーバーとリソースサーバーが実体として同じサーバーであることもある。</li>
</ul>
<h3>1.2 プロトコルの流れ</h3>
<ul>
<li>A: クライアントはリソースオーナーからの認証を要求する。認証の要求はリソースオーナーに対してそれを表示することで行われるか、認証サーバーが中継して行われることがある。</li>
<li>B: クライアントサービスは認証の同意を受け取る。その同意はリソースオーナーの認証を表現している信用である。その同意はこの仕様書で定義されている4つのgrant typeで表現される。もしくは拡張grant typeで表現される。認証grant typeは認証を要求するクライアントが使用しているメソッドに依存している。また、認証サーバーがサポートしている認証grant typeにも依存している。</li>
<li>C:クライアントは認証サーバーを使用した認証によってアクセストークンを要求する。そして認証grantを渡す。</li>
<li>D:認証サーバーはクライアントを認証し、認証grantを検証し、有効ならばアクセストークンを発行する。</li>
<li>E: クライアントはリソースサーバーから保護されたリソースをリクエストし、アクセストークンを示すことによって認証する。</li>
<li>F: リソースサーバーはアクセストークンを認証する。もし有効ならばリクエストを提出する。</li>
</ul>
<h3>1.3 認証grant</h3>
<ul>
<li>認証grantはリソースオーナーの認証を表す信用情報であり、クライアントによって、アクセストークンを取得するために使用される。この仕様書では
4つのgrant typeを定義している。</li>
</ul>
<h4>1.3.1 認証コード</h4>
<ul>
<li>認証コードはクライアントとリソースサーバーの仲介役としての認証サーバーを使用することによって取得される。</li>
<li>リソースオーナーから直接認証をリクエストされる代わりに、クライアントはリソースサーバーを認証サーバーに向かわせることができる。</li>
<li>リソースオーナーをクライアントに向かわせる前に認証サーバーはそのリソースオーナーを認証し、認証を手に入れる。</li>
</ul>


RFC6749のまとめ