[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.html>
More information about the Openid-specs-ab
mailing list