OAuth/WRAP : Accessing a Protected Resource (0.9.7.2 )

1.1 Accessing a Protected Resource

 

The Access Token is opaque to the Client, and can be any format agreed to between the Authorization Server and the Protected Resource enabling existing systems to reuse suitable tokens, or use a standard token format such as a Simple Web Token or JSON Web Token. 

Since the Access Token provides the Client authorization to the Protected Resource for the life of the Access Token, the Authorization Server should issue Access Tokens that expire within an appropriate time. 
When an Access Token expires, the Client requests a new Access Token from the Authorization Server, which once again computes the Client’s authorization, and issues a new Access Token. 

Diagram 1 below shows the flow between the Client and Authorization Server (A,B); and then between the Client and Protected Resource (C,D):

アクセストークンはClientにはわかりずらく、Authz ServerとProtected Resourceで同意した任意のフォーマット。
Simple Web TokenとかJSON Web Tokenとかが使える。

Access Tokenにより有効期間内の間のみClient認可がProtected Resourceに提供される。
Authz Serverは時間を有効期間を設定できる。
有効期間をすぎると、Clientは新しいAccess TokenをClientに要求するので、ClientはAuthz Serverに行って認可を処理してもらって新しいトークンをもらう。

図1はClientとAuthz Serverの間のフロー(A,B)と、ClientとProtected Resourceの間のフロー(C,D):

WS000033

In step A, the Client presents credentials to the Authorization Server in exchange for an Access Token. 
A Profile specifies the credentials and how the Client obtains them. 
This specification defines a number of Profiles; additional Profiles may be defined to support additional scenarios. 

AではClientはクレデンシャルをAuthz Serverに提示して代わりにAccess Tokenをもらう。
ProfileではクレデンシャルとクライアントがTokenをどうやって取得するかについて定義する。
ここではProfileのいくつかを定義する。

カテゴリー: 未分類 パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中