Thanks Prabath. Will read the spec & come up with necessary changes.
On Wed, Sep 11, 2013 at 4:08 PM, Prabath Siriwardena <[email protected]>wrote: > 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 > -- /sumedha b : bit.ly/sumedha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
