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

[Vladimir Dzhuvinov]

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/e4fe8abf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20171018/e4fe8abf/attachment.p7s>