You can refer to RFC 6749 - The OAuth 2.0 Authorization Framework
4.1 The authorization code grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients.Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
图4.1
The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
4.2 The implicit grant type
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
图4.2
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.
主要的区别是：
1. The authorization code grant是定义用来取access token 和 refresh token，The implicit grant type只定义了获取access token。
2. The authorization code grant是两个请求，分别用来进行认证和获取access token。The implicit grant type是一次请求直接获取access token。
3. The implicit grant type不提供客户端认证检查，而The authorization code grant在4.1步骤4有一个客户端检查的步骤。(图4.1)
4. The authorization code grant方法返回的uri中的认证和access token部分是传给请求方服务器。而The implicit grant type中的access token部分(fragment,通常以hash uri)在客户端本地处理，回调服务器不包含hash的部分(access token)。(图4.2)
4.1 The authorization code grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients.Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
图4.1
The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
4.2 The implicit grant type
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
图4.2
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.
主要的区别是：
1. The authorization code grant是定义用来取access token 和 refresh token，The implicit grant type只定义了获取access token。
2. The authorization code grant是两个请求，分别用来进行认证和获取access token。The implicit grant type是一次请求直接获取access token。
3. The implicit grant type不提供客户端认证检查，而The authorization code grant在4.1步骤4有一个客户端检查的步骤。(图4.1)
4. The authorization code grant方法返回的uri中的认证和access token部分是传给请求方服务器。而The implicit grant type中的access token部分(fragment,通常以hash uri)在客户端本地处理，回调服务器不包含hash的部分(access token)。(图4.2)
Authorization Code Grant Flow
ひとつめは，Authorization Code（認可コード）を使用する方法です。認可コードは，アクセストークンやリフレッシュトークンを得るために一時的に使用します。この方法は，Webサーバー上で動作するアプリの使用が想定されています。
OAuthでは，4種類のRole（ロール）が登場します。リソースオーナーは，アプリへアクセス許可を与える存在です。通常はアプリの利用者です。クライアントは，アプリを表します。認可サーバーは，認証・認可処理，認可コードやアクセストークン，リフレッシュトークンを発行します。リソースサーバーは，ユーザーデータ（リソース）を持っているサーバーです。
また，もうひとつ重要なのが，ユーザーエージェントです。通常，ユーザーエージェントはWebブラウザーのことです。リソースオーナーは，ユーザーエージェントを通してクライアントやサーバーとやりとりします。
フローの手順は次の通りです。アプリ利用者がWebサイトにアクセスした後から始まります。
①認証・認可画面（Webページ）へ移動します。通常，Webページにサインイン ボタンなどを表示し，アプリ利用者のクリックで移動します。移動先のLive Connect認可サーバーのエンドポイントは，以下のURLです。
URLのクエリーには，Client ID（クライアントID），スコープ，リダイレクト先のURLなどを指定します。
②リソースオーナーは，Windows Liveサービスへのサインインと，アプリが要求する内容を許可します。
③①で指定したリダイレクト先へ移動します。このとき，認可サーバーは，URLのクエリーに認可コードを付けてリダイレクトします。
Webアプリは，ユーザーエージェントを介して認可コードを受け取ります。
④クライアントは，認可サーバーにアクセストークンを要求します。次のURLにアクセスします。
URLのクエリーには，クライアントID，リダイレクトURL，Client Secret（クライアントシークレット），認可コードなどを指定します。
⑤認可サーバーは，アクセストークンを発行します。
以上が，認可のフローです。リフレッシュトークンは，リソースオーナーに認可された場合，アクセストークンと一緒に発行され，クライアントが受け取ります。
⑥クライアントは，リソースサーバーにリソースのアクセスを要求します。Live Connectでは，REST APIを利用します。
Implicit Grant Flow
もうひとつのアクセストークンを取得する方法は，Webブラウザー上で動くアプリ向けの方法です。JavaScript APIはこの方法を使っています。デスクトップアプリでも使えます。
この場合のクライアントは，JavaScriptなどで実装されたWebブラウザー上で動作するアプリです。Webサーバーには，クライアントのリソース（HTML文書やスクリプト）があります。
フローの手順は次の通りです。
①認証・認可画面（Webページ）へ移動します。
②リソースオーナーは，Windows Liveサービスへのサインインと，アプリが要求する内容を許可します。
③①で指定したURLへリダイレクトします。このとき，認可サーバーは，URLのフラグメントにアクセストークンを付けてリダイレクトします。
④ユーザーエージェントは，Webサーバー上のクライアントリソースのURLへリダイレクトします。このとき，URLの#以降のフラグメント部分にあるアクセストークンは，Webサーバーには送信されません。
⑤クライアントリソースは，JavaScriptなどのスクリプトを含むHTML文書を返します。
⑥ユーザーエージェントは，スクリプトを実行し，URLのフラグメントからアクセストークンを抽出します。
以上が，認可フローです。リソースへのアクセスは図では省略しています。リソースのアクセスは，ユーザーエージェントがアクセストークンを使ってリソースサーバーへ要求します。
ひとつめの認可コードを使う場合と比べると，アクセストークンをユーザーエージェントが持っている点が大きく異なります。また，この方法の場合，認可サーバーはリフレッシュトークンを発行しません。
以上が，OAuthで定義されている4種類のフローのうちの2種類でした。Live Connectでは，これ以外にJavaScript APIとサインインコントロールを使用したフローを用意しています。
0 件のコメント :
コメントを投稿