diff --git a/draft-richer-oauth-chain.xml b/draft-richer-oauth-chain.xml index 6dba631..6a37a93 100644 --- a/draft-richer-oauth-chain.xml +++ b/draft-richer-oauth-chain.xml @@ -10,12 +10,13 @@ - + A Method of Bearer Token Redelegation and Chaining for OAuth 2 - + The MITRE Corporation
@@ -33,13 +34,43 @@ +1-781-271-8176 - + jricher@mitre.org
- + + Oracle Corporation + +
+ + + + + + + + + + + + + + + + + phil.hunt@yahoo.com + + +
+ + + + + Security + + OAuth Draft @@ -93,12 +124,16 @@
- Authorization Server - Client Resource Owner + Authorization Server that issues tokens for + Primary Resource Server (RS1) + + Authorization Server that issues tokens for + Chained Resource Server (RS2), MAY be the same as AS1 + Primary Resource Server, initially called by C on behalf of RO @@ -116,7 +151,7 @@
The process begins with any standard OAuth2 protocol flow, where the - client obtains AT1 from the AS. + client obtains AT1 from AS1.
The beginning of the process is standard OAuth2 §1.2 @@ -131,22 +166,22 @@ | | | | +---------------+ | |--(C)----------------------->| Authorization | - | Client | | Server | - | |<-(D)------------------------| (AS) | - | | | | - | | | | - | | +-------------+ | | - | |--(E)->| Primary |--(F)->| | - | | | Resource | | | - | | | Server |<-(G)--| | - | | | (RS1) | +---------------+ - | | | | - | | | | +---------------+ - | | | |--(H)->| Chained | - | | | | | Resource | - | | | | | Server | - | | | |<-(I)--| (RS2) | - | |<-(J)--| | +---------------+ + | | | Server 1 | + | |<-(D)------------------------| (AS1) | + | | +---------------+ + | | + | Client | +-------------+ +---------------+ + | |--(E)->| |--------------(F)----------->| Authorization | + | | | | | Server 2 | + | | | |<-------------(G)------------| (AS2) | + | | | Primary | +---------------+ + | | | Resource | + | | | Server | +---------------+ + | | | (RS1) |-------------(H)------------>| Chained | + | | | | | Resource | + | | | | | Server | + | | | |<------------(I)-------------| (RS2) | + | |<-(J)--| | +---------------+ +--------+ +-------------+ @@ -160,23 +195,24 @@ Client receives authorization from the Resource Owner using any valid OAuth2 grant type - Client requests AT1 from the AS by authenticating - with the AS and presenting the authorization grant obtained in + Client requests AT1 from the AS1 by authenticating + with the AS1 and presenting the authorization grant obtained in (B) - AS authenticates the Client and issues access + AS1 authenticates the Client and issues access token AT1 for use at RS1 Client presents access token AT1 to RS1 to access a protected resource RS1 needs to access RS2 to fulfill this request, - makes a call to the Token Endpoint on the AS using the redelegate + makes a call to the Token Endpoint on the AS2 using the redelegate grant_type - AS validates AT1 and issues a token AT2 for use by - RS1 against RS2, where the rights assigned to AT2 are a subset of - those assigned to AT1 + AS2 validates AT1 (using methods outside the scope + of this specification) and issues a token AT2 for use by RS1 against + RS2, where the rights assigned to AT2 are a subset of those assigned + to AT1 RS1 presents AT2 to RS2 to access a protected resource @@ -209,8 +245,8 @@ Server's Token Endpoint with the following parameters: - REQUIRED. Value MUST be set to - "urn:ietf:params:oauth:grant_type:redelegate". + REQUIRED. Value MUST be set to urn:ietf:params:oauth:grant_type:redelegate REQUIRED The token that was presented to the resource server by the client, referred to as AT1 in the protocol @@ -254,7 +290,7 @@
If the token request is not valid, such as the access token presented does not allow for redelegation, the AS returns an error - response as described in OAuth2 Core. + response as described in OAuth2.
@@ -275,6 +311,15 @@ of scopes required for accessing the full service chain. A redelegation request MUST NOT request escalated privileges without involving the resource owner in a new authorization grant. + + OAuth protected servers within the same domain, using the same Token + server, MAY request new OAuth tokens for the purpose of binding the + original user context with the new client credential. + + When issuing tokens between OAuth domains, the token server MUST be + able to determine the submitted token's issuer. The token server SHOULD + have a method of establishing trust with the issuer of the received + OAuth token.
@@ -286,18 +331,20 @@ + + - + <author> - <organization></organization> + <organization/> </author> - <date year="2004" /> + <date year="2004"/> </front> </reference> </references>