[Openid-specs-ab] Question on access token w multiple audiences and multiple resource servers

rich levinson rich.levinson at oracle.com
Tue Oct 17 19:10:49 UTC 2017

Here is a real world analogy:

 1. My company issues me a badge that grants access to the 3rd floor AND
      to Conference Room 5 on the 3rd floor.
 2. I use the badge to enter the 3rd floor.
 3. I use the same badge to enter Conference Room 5.


On 10/17/2017 3:04 PM, rich levinson via Openid-specs-ab wrote:
> Does anyone have guidance on validity of the following scenario?:
>     There is a Resource Server, RS-1, that, in order to provide its service
>     needs to also access a downstream Resource Server RS-2.
>     When the oauth client requests an access token, it is granted an access token
>     by the az-svr (that knows that both RS-1 and RS-2 must be used) that
>     contains 2 audiences: RS-1 and RS-2.
>     The oauth client uses the access token to access RS-1.
>     RS-1, in turn, uses the same access token to access RS-2.
>     The response is returned from RS-2 to RS-1.
>     RS-1 combines the response from RS-2 w its own resp and
>      returns the combined response to the oauth client.
> Given that the token is a bearer token it seems to me there is no reason why
> both the oauth client AND the RS-1 can't use the access token to get what they
> need, w/o RS-1 having to register itself as a separate client and get its own
> access token.
> So, the question is whether this is a legitimate use case for a resource server
> to access downstream services.
>   Thanks,
>   Rich
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=a6VgxOtTmWHZYkdmMlFsZ7ZfJF5J6d9dmCwLNKaCqAU&s=Fx_11CM3YgV1k9Mxzey2kasEdBiVMA9M3gk5SL7ifMw&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20171017/f322eaa3/attachment.html>

More information about the Openid-specs-ab mailing list