<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Vladimir,<br>
<br>
Yes, I have reached the conclusion that "on-behalf-of" will address
the situation<br>
I am looking at and that "on-behalf-of" has now morphed into token
exchange:<br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09">https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09</a><br>
<br>
The basic flow is as follows, building on the notation used in the
original proposal/question:<br>
<ol>
<li>oauth client sends access token to RS1.</li>
<li>RS1 validates the token and grants access.</li>
<li>RS1 sends its own client creds to az-svr, along w access token
and<br>
receives new access token to allow it to access RS2.</li>
<li>RS2 sends new access token to RS2.</li>
<li>RS2 validates new access token and grants access.</li>
</ol>
I think this is good solution, as it allows unlimited chaining and
callbacks, as long as<br>
az-svr is willing to grant the next access token.<br>
<br>
In addition, mutual TLS can, in parallel to any or all steps in the
chain separately, as<br>
each step consists of a call to az-svr to get token, then call to
RSn+1 to get downstream<br>
access.<br>
<br>
Thanks,<br>
Rich<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/18/2017 4:21 AM, Vladimir
Dzhuvinov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f5271ed3-c1b3-92f9-8db4-39b3978a9dc3@connect2id.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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"
moz-do-not-send="true">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="
moz-do-not-send="true"><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"
moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E"
href="mailto:openid-specs-ab@lists.openid.net"
moz-do-not-send="true"><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"
moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E"
href="mailto:Openid-specs-ab@lists.openid.net"
moz-do-not-send="true"><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"
moz-do-not-send="true">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="
moz-do-not-send="true"><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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>