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

Wed Oct 18 19:32:56 UTC 2017

Hi Filip,

I think the difference is that rfc 7523:
   https://tools.ietf.org/html/rfc7523#section-2.2

uses the token for client authentication.

In the token exchange spec:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1

the client does its normal OAuth2 authentication (client-id, client-secret
i.e. NOT the token to be exchanged),
and the token to be exchanged is provided as a parameter
  (

   subject_token
       REQUIRED.

  )
as the access token that is to be exchanged for the new token.

At least that's my high-level takeaway based on looking thru the token exchange
spec and concluding that it is 99% likely to solve the problem as I described
in prev email.

   Thanks,
   Rich

On 10/18/2017 12:50 PM, Filip Hanik wrote:
> sounds similar to
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Djwt-2Dbearer-2D12&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=c7JD8uopyJJoaWbHa4Z8e0I3bX4f3ggCc7BH_n-mPJs&e=>
>
> On Wed, Oct 18, 2017 at 9:41 AM, rich levinson via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>
>     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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=kZIyTo2crIB-5-lx4o_F9e61yLli1TjP1Nmm_S_mmRc&e=>
>
>     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=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=gDhERmH-a0O5odt7G5PaxBxbrb1P8Jln1KTTpfLR794&e=> <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=>
>>>>     <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> <mailto: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> <mailto: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=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e=> <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=> <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 <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=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e=>
>>
>
>
>     _______________________________________________
>     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=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e=>
>
>

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