Just as a point of clarification, the definition of the “azp” claim is not “authorised presenter”. At least as defined by OpenID Connect, its definition is:
azp OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case sensitive string containing a StringOrURI value. A reference to this definition is registered by OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.html in the IANA “JSON Web Token Claims” registry at http://www.iana.org/assignments/jwt/jwt.xhtml. -- Mike From: OAuth [mailto:[email protected]] On Behalf Of Nat Sakimura Sent: Tuesday, August 18, 2015 7:37 PM To: Adam Lewis Cc: OAuth WG Subject: Re: [OAUTH-WG] RS as a client guidance It is not directly, but Sender Constrained JWT for OAuth 2.0 ( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DhL9%2bp5Ml32P6%2fdaAQHHkho1yCsbq2W0M4WNrwgo1zo%3d> ) 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eM%2f2nMY4YEca%2fyZtl6K4f4pRceNCHt1sF7v9ufZ7qgk%3d> -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2x5%2f9bLJnUcMdOFrYWIk4G0BIwp8ytDK2LNx2BQuTtk%3d> @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
