[Openid-specs-ab] App2app authorization/authentication

Joseph Heenan joseph at authlete.com
Wed Oct 9 09:00:24 UTC 2019

Hi George,

Thanks for your thoughts! I’ve made some replies inline:

> On 8 Oct 2019, at 15:28, George Fletcher <gffletch at aol.com> wrote:
> It might be possible to extend the Native SSO spec to work across apps from different vendors using this method.

I’m not sure I see the overlap that would make extension possible; device_secret would not be applicable in the cross-company case I believe? (Am I right to characterise device_secret as being the real essential addition in native SSO? And it’s rather off topic, but I’m interested to know the pro/cons of using what I believe is sort-of a shared secret vs using the Secure Enclave to create a key, and using proof of possession of that key via a signed jwt to demonstrate that you’re an app from the same device.)

You can certainly use the two specs together so that app2app is used for the initial authentication/authorization build the initial linkage from device app group to idp, with “native app from the company providing the iDP” replacing “system browser” in https://openid.net/specs/openid-connect-native-sso-1_0.html

> 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.

The client id and all authorization parameters are passed from the third party app (relying party) to the first party app (associated with the iDP) in exactly the same manner as they would be passed to the AS’s authorization endpoint. This is a key part of the simplicity of app2app - the relying party app has to do almost nothing different to the standard “third party app using a browser to obtain an authorization code” pattern.

> 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.

Yes, potentially - I suspect there’s [at least] two different models in the wild, depending on whether the bank app itself is an oauth client or is merely a frontend for a oauth client implemented on the bank’s server.

> 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.

The request/response between the two apps is already standardised, it’s the normal “open the authorisation endpoint in a user agent” flow.

I think there’s definitely mileage in trying to standardise the idp app <-> idp message. I’ve reached out to a couple of vendors to see if they can share how they currently do this.

> 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.
> Are there any security issues with the on OS app2app communication that would allow for cut-and-paste attacks?

I don’t believe so [assuming the mobile OSes correctly secure claimed https urls, which I believe they do and would cause a lot of other security problems if they didn’t, as the native apps BCP already recommends this mechanism for redirect urls for native apps] - if anything I would say it is more secure than the approaches where the user agent for the authorization endpoint is a desktop browser.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191009/241c04a8/attachment-0001.html>

More information about the Openid-specs-ab mailing list