Hi Sumedha, This needs to be better modeled after "A Method of Bearer Token Redelegation and Chaining for OAuth 2"
http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt The grant type needs to be urn:ietf:params:oauth:grant_type:redelegate And also - we should not provide a refresh token in the response. Thanks & regards, -Prabath On Mon, Sep 9, 2013 at 9:36 PM, Sumedha Rubasinghe <[email protected]> wrote: > *Pattern* > There are multiple backend systems having its own authentication and > authorization mechanisms. These sub systems do not trust each other. > > In order to fulfill an API invocation from an end user, several of these > back ends need to be accessed. The number of internal systems that need to > be accessed is transparent to application developer and only known to API > publisher and implementor. However for statistical reason access need to > happen as if its coming from the end user + internal backend system. > > Thus comes the need for delegating access on behalf of end user. > > *Implementation* > Initial API access will happen through an OAuth2 token (obtained on > behalf of end user through standard grant types). > This API call will reach first backend system. When this backend system > needs to access some other system, it will obtain an OAuth2 token on behalf > of the end user. However, at this point only original OAuth2 token is > available to represent end user. > > Thus token to second system is obtained by passing, > *consumer key + consumer secret + OAuth2 token passed into access first > system* > > This combination is not supported by any of standard grant types defined > in OAuth2. Thus we would support the above pattern using a extended grant > type called "trusted_delegation". > > The syntax for invoking this grant type is as follows: > *HTTP Header:* > Authorization : Basic 'Base64.encode(consumer key . Consumer secret)' > > *Request parameters:* > grant_type=trusted_delegation&enduser_token=wsdr23djdedv > > Response would be as follows: > { > "token_type":"bearer" > ,"expires_in":3600 > ,"refresh_token":"f592b7403f3225d22f4b8e8510928e47" > ,"access_token":"5abbabd324fdcd697591b83c7b6eef3" > } > > > Thanks to Prabath for help on solidifying solution criteria and grant type > name. > I have implemented the first draft and will schedule a code review session. > > > *Pending:* > 1. Revoke - when end user decides to revoke his token, all tokens issued > on behalf of him (and stored on intermediate sub-systems) should be revoked. > > > -- > /sumedha > b : bit.ly/sumedha > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
