[Openid-specs-ab] App2app authorization/authentication

George Fletcher gffletch at aol.com
Tue Oct 8 14:28:02 UTC 2019

It might be possible to extend the Native SSO spec to work across apps 
from different vendors using this method.

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.

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


On 10/3/19 1:21 PM, Joseph Heenan via Openid-specs-ab wrote:
> Hi Nov,
> Replies inline:
>> On 3 Oct 2019, at 14:15, nov matake <nov at matake.jp> 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.
> 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.
>> I think George has another way in his native app SSO draft.
> 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
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191008/8a5e2853/attachment.html>

More information about the Openid-specs-ab mailing list