It is not directly, but Sender Constrained JWT for OAuth 2.0 ( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 ) talks about a model that allows it.
In essence, it uses a structured access token that is sender constrained. It as a claim "azp" which stands for authorised presenter. To be used, the "client" has to present a proof that it is indeed the party pointed by "azp". In your case, the native mobile app obtains the structured access token with "azp":"the_RS". Since "azp" is not pointing to the mobile app, the mobile app cannot use it. The mobile app then ships it to the RS. The RS can now use it since the "azp" points to it. In general, shipping a bearer token around is a bad idea. If you want to do that, I think you should do so with a sender constrained token. Nat 2015-08-13 2:01 GMT+09:00 Adam Lewis <[email protected]>: > Hi, > > Are there any drafts that discuss the notion of an RS acting as a client? > I'm considering the use case whereby a native mobile app obtains an access > token and sends it to the RS, and then the RS uses it to access the > UserInfo endpoint on an OP. > > It's a bearer token so no reason it wouldn't work, but obviously it is > meant to be presented by the client and not the RS. Curious to understand > the security implications of this, read on any thoughts given to this, or > to know if it's an otherwise accepted practice. > > tx > adam > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
