<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">It might be possible to
extend the Native SSO spec to work across apps from different
vendors using this method.<br>
<br>
It seems to me that how the requesting app specifies it's
"client_id" and other authorization parameters is out of scope for
the flow. Also, how an AS decided to honor the authorization
request and return a code:state pair to an intermediary is also
not defined within OIDC/OAuth2. I would expect that the AS will
want "client authentication" from the bank app as well as "client
identification" of the 3rd party app.<br>
<br>
From a standardization perspective, it seems like specifying the
request/response between the 3rd party app and "IdP App" as well
as specifying the special call between the "IDP App" (profile of
token exchange?) would complete the picture.<br>
<br>
The Native SSO spec could provide a starting point for how the
"IdP App" identifies the user to the back-end AS in a secure way
as well as possibly the profile of the token-exchange. In the case
of Native SSO, the response of the token-exchange is the actual
tokens where in this case it would need to be the "code and state"
values going back to the 3rd party app.<br>
<br>
Are there any security issues with the on OS app2app communication
that would allow for cut-and-paste attacks?<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 10/3/19 1:21 PM, Joseph Heenan via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EA4FBE61-FDA6-4A8D-87FA-3F2FE3D1538F@authlete.com">
<pre class="moz-quote-pre" wrap="">Hi Nov,
Replies inline:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 3 Oct 2019, at 14:15, nov matake <a class="moz-txt-link-rfc2396E" href="mailto:nov@matake.jp"><nov@matake.jp></a> wrote:
My use-case isn't app2app, but it's making the mobile apps the self-issued IdP for the backend IdP.
In that case, the first logged-in app registers a public key to the backend IdP server. After that, when following app send AuthZ request to the server, the server returns another AuthZ request to the app itself. Then the app authenticate user via TouchID etc and acts as self-issued IdP against the backend. Receiving self-issued ID Token, backend IdP authenticates the user and issue code.
If the app can acts as IdP of the backend IdP, you won't need vendor-specific way to issue code.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'm quite interested in this. Is this chaining of a self-issued iDP to a backend iDP an already defined protocol I can read more about somewhere?
I'm not sure if it would be the most natural way to do it; the first party app (the bank app) is generally also an oauth client of the backend idp, and the approaches I've seen so far for app2app leverage that existing client relationship. Sadly I'm not aware of anyone that's publicly documented how their implementation of the first party app interacts with the iDP to implement the app2app case.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I think George has another way in his native app SSO draft.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I don't yet fully understand George's draft, but it only works where the apps are from the same company, so it does not help in the general app2app scenario (where the apps are from different companies) as far as I know.
Thanks
Joseph
_______________________________________________
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>