Thanks for the review Erik, We will go through it in detail and get back to you.
I am working with a couple of governments on how a eID app could use the self issued profile of OpenID Connect to issue tokens. There are also other out of band authentication apps that people use that need to be considered. I think that the callback / redirect_uri can work if a custom scheme URI or a app claimed https: URI is used. I agree that sniffing the URI in a web view creates a very confusing user experience at the moment. It works better on Android than iOS 8 but is not smooth in many cases. I personally use a out of band mobile authenticator for my enterprise login that has exactly that problem, and requires me to manually switch back to the calling app. Regards John B. > On Jul 24, 2015, at 12:59 AM, Erik Wahlström <e...@wahlstromstekniska.se> > wrote: > > Hi, > > Thanks for a great document! I volunteered to review > draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go: > > > In national mobile eID deployments an app is issued by gov or other > organisation in a country. The app acts as the users authentication method > and it works with an IDP, the IDP can be anywhere if its an PKI token or at > the place that issued the credential if it’s something else. When an SP start > developing an native app for there services and want’s to use the national > eID solution in combination with OAuth we might run into trouble here. > > The flow is like follows for a service provider called FooBar: > > FooBar’s app starts browser-view. FooBar’s SAML service provider > functionality redirects the user to an national SAML IDP. The IDP prompts > user for a username and then starts an mobile eID token on the same phone. > Users is asked if they want’s to authenticate to FooBar and enters PIN. User > are then redirected back with an assertion. The FooBar's service provider > verifies the assertion and mint’s OAuth2 token(s) and redirects the user back > to the app with the help of the redirect URL. > > So the phone first displays an app, then foobar.com <http://example.com/> in > browser-view, then idp.com <http://nationalidp.com/> in browser-view, then > mobile eID token, then idp.com <http://nationalidp.com/> in the system > browser and back to foobar.com <http://example.com/> and the app that the > user wanted to use. > > The problem with browser-views is that the mobile eID token will start > idp.com <http://idp.com/> when user has authenticated and then the user is > not back in the apps browser-view, but in system browser instead. The system > browser is sharing the session with the browser-view and redirect the user to > the native app. The user experience will be a bit strange then because there > the correct page is not loaded and the browser-view should be closed and the > app should start parsing out the authorization code instead. > > So I think draft should mention something about this scenario and that app > developers should handle this scenario in the app. The grant did not really > come back from the browser-view as expected but from the system browser > instead. > > ————————— > > With the above in mind. Maybe even some example code would be nice to have in > the non normative section "Appendix A. Operating System Specific > Implementation Details”. Especially how to handle call backs. > > ————————— > > Another eID related issue is the pricing model for authentications in that > market segment. It’s really common by the eID credential issuing > organisations to charge a service providers usage of a credential per tick > (that is by OSCP call). The system is based on a per tick pricing model and > there are regulations for how long the sessions can live. That means that its > not possible to authenticate with a token once and then create a refresh > token and the user will ever see the authentication flow again. It kinda > messes up the usability of mobile apps a lot but end users have come to term > with it. They have not however came to term to always require consents every > time they use the app. That drives end user crazy. The usability would be > much better if the payment model also accepted a refresh token as a tick > instead of just an OSCP call, but we are not there yet. > > Anyway, that’s the backstory. The section "6.4. Always Prompting for User > Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to a > NOT RECOMMENDED. > > ————————— > > Two additional things that strengthen the case for using the browser-view > also come to mind when reading the draft. The first is the fact that multiple > tabs is started in some browser when going through multiple authentication > attempts. That clutters the system so I really like the new browser-views. > > The second is that there are additionally nice things in browser-view that do > not exist in the web-view. The localStorage is also preserved and it can > include important information to make authentication methods more secure. > > ———————— > > "Authorization servers SHOULD consider taking steps to detect and > > block logins via embedded user-agents that are not their own, where > > possible."" > > > > Sounds good, but that also sounds very hard when it comes to public clients. > > ————————— > > And some nits: > > > > "OAuth flows between a native app and the system browser (or another > > external user-agent) are more secure, and take advantage of the > > shared authentication state." > > > > Not really clear what shared authentication state that is in that sentence. > > > > "When the authentication server completes the request, it redirects to > > the client's redirection URI like it would any redirect URI" > > > > s/authentication/authorization > > > > / Erik > > > > > > > On Thu, Jul 23, 2015 at 6:22 PM, <oauth-requ...@ietf.org > <mailto:oauth-requ...@ietf.org>> wrote: > > John Bradley and I introduced a new draft at IETF93 yesterday: > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 > <https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00> > > > Goal is to provide best practices for native apps using the RFC6749 > authorization > endpoint, expanding on RFC6749 Section 9. Specifically, it recommends > using an external user-agent (such as the system browser) for this task > over an embedded user-agent (such as a web-view), and suggests ways to > achieve this. > > > Comments welcome! > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
