Re: [OAUTH-WG] Authorization handover from mobile app to website

["SOMMER, DOMINIK" <[e-mail]>]

I have to admit I can’t read the slides, and the flows aren’t quite self-explanatory. However, just based on the headline I can’t quite figure out how to make a client “in the wild” (= the mobile app) a trusted IdP for a backend. This would basically allow anyone reverse-engineering the app (and it’s keypair) to generate arbitrary ID tokens.

However, I probably get something wrong ☺

- Dominik

Von: Nov Matake <[e-mail]>
Gesendet: Samstag, 13. März 2021 05:00
An: SOMMER, DOMINIK <[e-mail]>
Cc: [e-mail]
Betreff: Re: [OAUTH-WG] Authorization handover from mobile app to website

You can make your app an OIDC self-issued IdP for your website.

One of my clients are using the mechanism for Native App SSO, where an OIDC self-issued IdP embedded in the Native App is acting as IdP for the backend IdP server.

Unfortunately I have no english document now, but this slide describes the mechanism.
https://speakerdeck.com/rtechkouhou/openid-connect-self-issued-idpwoying-yong-sitasingle-sign-onfalseshi-zhuang
iPadから送信


2021/03/13 3:24、SOMMER, DOMINIK <[e-mail]<mailto:[e-mail]>>のメール:

Hi all,

we have recently launched a mobile app that uses our website’s login and authorization code flow to authenticate and authorize user access (following RFC8252).

However, not all of our website features are natively ported to the app itself. Some are only available on the website in logged-in state. That’s why we implemented an authorization handover mechanism based on one-time login codes: This allows the app (in logged-in state) to open a web view and hand over authentication & authorization, effectively logging the user in on the website. This achieves a seamless experience for the user without compromising on security.

We came up with this mechanism after researching for prior practice, but we couldn’t find anything applicable for this scenario.

Hence, three questions to the list:
1. Did we miss anything in our research? Is there a common best practice available?
2. If the answer to 1. is “No”, would the working group appreciate an RFC draft describing the solution we came up with? (We’d be eager for comments to make it even more secure ☺ )
3. If the answer to 2. is “Yes”, can someone point me to documentation on the procedure, if such exist?

Thanks for your support and
best regards,
Dominik

Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 116409
Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt


Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 116409
Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth