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

rich levinson rich.levinson at oracle.com
Wed Oct 18 16:41:05 UTC 2017


Hi Vladimir,

Yes, I have reached the conclusion that "on-behalf-of" will address the situation
I am looking at and that "on-behalf-of" has now morphed into token exchange:
   https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09

The basic flow is as follows, building on the notation used in the original proposal/question:

 1. oauth client sends access token to RS1.
 2. RS1 validates the token and grants access.
 3. RS1 sends its own client creds to az-svr, along w access token and
      receives new access token to allow it to access RS2.
 4. RS2 sends new access token to RS2.
 5. RS2 validates new access token and grants access.

I think this is good solution, as it allows unlimited chaining and callbacks, as long as
az-svr is willing to grant the next access token.

In addition, mutual TLS can, in parallel to any or all steps in the chain separately, as
each step consists of a call to az-svr to get token, then call to RSn+1 to get downstream
access.

   Thanks,
   Rich


On 10/18/2017 4:21 AM, Vladimir Dzhuvinov wrote:
> On 17/10/17 22:33, rich levinson via Openid-specs-ab wrote:
>> Hi Linus,
>>
>> I agree there may be some issues introduced by Mutual TLS.
>>
>> However, in principle, access tokens are bearer tokens and there really is no
>> implicit control on what entity is using the access token.
>>
>> For example, if the oauth client trusts RS-1 to deliver a service, then
>> it should trust RS-1 to use the token to access RS-2.
>>
>> Possibly Mutual TLS could be extended to cover the RS-1<->RS-2 connection
>> as well.
> I don't see how mTLS could be extended to cover this scenario. When the token is issued, it gets bound to the client's certificate. The RS-1 is not present at this point, so I see no direct way to for the AS to add secondary binding to the RS-1 certificate.
>
> Did you look at token exchange?
>
> (draft-ietf-oauth-token-exchange-09)
>
> Vladimir
>
>> Thanks,
>>   Rich
>>
>>
>> On 10/17/2017 3:19 PM, Linus Lewandowski wrote:
>>> Hi,
>>>
>>> This won't really be possible with Mutual TLS <https://tools.ietf.org/id/draft-ietf-oauth-mtls-03.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dietf-2Doauth-2Dmtls-2D03.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=tb9zOhjteWWIATXzVc3HJCrh6hqsYhws1Yn11x8GiBg&s=GTdDEw8rKcAS_akoL4N2C8PYXbN8wG3H4JtBMenjwjA&e=>>
>>>
>>> Without Mutual TLS, this means that RS-1 can impersonate your app when talking to RS-2, and RS-2 when talking to RS-1. Not ideal from the security POV.
>>>
>>> Regards,
>>> Linus
>>>
>>> On Tue, Oct 17, 2017 at 9:04 PM rich levinson via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> 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 <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=tb9zOhjteWWIATXzVc3HJCrh6hqsYhws1Yn11x8GiBg&s=6xTtGMr1rtCrSdJzSj_eq1FPnPRxDTIfb3jLJvIfKwY&e=>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

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


More information about the Openid-specs-ab mailing list