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

rich levinson rich.levinson at oracle.com
Thu Oct 19 20:02:12 UTC 2017


Hi Filip,

I think you may be right.

So, what I think you are saying is that in use case 2.1:
     https://tools.ietf.org/html/rfc7523#section-2.1

  that, as indicated, client authentication is done by the usual means
  (https://tools.ietf.org/html/rfc6749#section-3.2.1),

that the assertion parameter contains the original access token that
the OAuth client provided when accessing RS1, and that as a result
the az-svr will return an access token so that RS1 can access RS2,
which is effectively what the chain scenario requires.

If so, then I think that this is effectively the token exchange that I am
looking for.

I will need to explore it in a bit more depth to ensure it meets all our
needs, but it sounds like it might work.

   Thanks,
   Rich


On 10/19/2017 1:27 PM, Filip Hanik wrote:
> https://tools.ietf.org/html/rfc7523#section-2.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523-23section-2D2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=pz0dshT3-quRewz0KqrgzeU4hdsyOiqM-x81aEpozJo&e=> and section 2.2 are two different use cases.
>
> in the main use case (section 2.1), the JWT token is the assertion for the user's identity. Client authentication is still done the same was as per https://tools.ietf.org/html/rfc6749#section-3.2.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6749-23section-2D3.2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=HViQju-y-Xmx0WVX8tlaZBpGNm-vN2PUvZHNmnRsg3o&e=>
>
> I would say that these two specs overlap very much. with the token exchange being targeted at the generic Oauth2 eco system, while rfc 7523 is a bit more specific to the OIDC context.
>
> Filip
>
> On Wed, Oct 18, 2017 at 12:32 PM, rich levinson <rich.levinson at oracle.com <mailto:rich.levinson at oracle.com>> wrote:
>
>     Hi Filip,
>
>     I think the difference is that rfc 7523:
>     https://tools.ietf.org/html/rfc7523#section-2.2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523-23section-2D2.2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=GR31ExtfzAJMxq9vy4EWgZZPmoeA93LwnqemSTTBOfE&e=>
>
>     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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=JKeyfeoaBFgjN3HDxgyJXChtbotFH5SD2TiMxoE3G5g&e=>
>
>     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/20171019/7a991743/attachment-0001.html>


More information about the Openid-specs-ab mailing list