<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 17/10/17 22:33, rich levinson via Openid-specs-ab wrote:<br>
<blockquote type="cite"
cite="mid:956f1517-4ea9-4282-0886-8f6772794daa@oracle.com">Hi
Linus,
<br>
<br>
I agree there may be some issues introduced by Mutual TLS.
<br>
<br>
However, in principle, access tokens are bearer tokens and there
really is no
<br>
implicit control on what entity is using the access token.
<br>
<br>
For example, if the oauth client trusts RS-1 to deliver a service,
then
<br>
it should trust RS-1 to use the token to access RS-2.
<br>
<br>
Possibly Mutual TLS could be extended to cover the
RS-1<->RS-2 connection
<br>
as well.
<br>
</blockquote>
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.<br>
<br>
Did you look at token exchange?<br>
<br>
<pre wrap="">(draft-ietf-oauth-token-exchange-09)</pre>
<br>
Vladimir<br>
<br>
<blockquote type="cite"
cite="mid:956f1517-4ea9-4282-0886-8f6772794daa@oracle.com">
Thanks,
<br>
Rich
<br>
<br>
<br>
On 10/17/2017 3:19 PM, Linus Lewandowski wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
This won't really be possible with Mutual TLS
<<a class="moz-txt-link-freetext" href="https://tools.ietf.org/id/draft-ietf-oauth-mtls-03.html">https://tools.ietf.org/id/draft-ietf-oauth-mtls-03.html</a>
<a class="moz-txt-link-rfc2396E" href="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=></a>><br>
<br>
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.
<br>
<br>
Regards,
<br>
Linus
<br>
<br>
On Tue, Oct 17, 2017 at 9:04 PM rich levinson via
Openid-specs-ab <<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab@lists.openid.net"><mailto:openid-specs-ab@lists.openid.net></a>> wrote:
<br>
<br>
Does anyone have guidance on validity of the following
scenario?:
<br>
<br>
There is a Resource Server, RS-1, that, in order to
provide its service
<br>
needs to also access a downstream Resource Server RS-2.
<br>
<br>
When the oauth client requests an access token, it is
granted an access token
<br>
by the az-svr (that knows that both RS-1 and RS-2 must
be used) that
<br>
contains 2 audiences: RS-1 and RS-2.
<br>
<br>
The oauth client uses the access token to access RS-1.
<br>
<br>
RS-1, in turn, uses the same access token to access
RS-2.
<br>
<br>
The response is returned from RS-2 to RS-1.
<br>
RS-1 combines the response from RS-2 w its own resp and
<br>
returns the combined response to the oauth client.
<br>
<br>
Given that the token is a bearer token it seems to me there
is no reason why
<br>
both the oauth client AND the RS-1 can't use the access
token to get what they
<br>
need, w/o RS-1 having to register itself as a separate
client and get its own
<br>
access token.
<br>
<br>
So, the question is whether this is a legitimate use case
for a resource server
<br>
to access downstream services.
<br>
<br>
Thanks,
<br>
Rich
<br>
<br>
_______________________________________________
<br>
Openid-specs-ab mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Openid-specs-ab@lists.openid.net"><mailto:Openid-specs-ab@lists.openid.net></a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<a class="moz-txt-link-rfc2396E" href="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=></a><br>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>