<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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>
<br>
Thanks,<br>
Rich<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/17/2017 3:19 PM, Linus
Lewandowski wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAB96meb+mY_0B-44TdxJ2YyXMn433HJNiTyw687bAfTz-kY8VQ@mail.gmail.com">
<div dir="ltr">Hi,
<div><br>
</div>
<div>This won't really be possible with Mutual TLS <<a
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="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/id/draft-ietf-oauth-mtls-03.html</a>></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,<br>
Linus</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 17, 2017 at 9:04 PM rich levinson
via Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Does anyone have
guidance on validity of the following scenario?:<br>
<blockquote>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>
</blockquote>
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>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
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="
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>