hi, let me give you an example of what is my concern. I admit this example is a bit extreme but still As said one popular redirect_uri used by mobile app is http://localhost.
Let’s also say a resource owner use this mobile app the first time and approve the consent screen and so forth…. It also turn out this resource owner is a developer :) and it runs one application on its own computer. This application runs as well on localhost. Now, and as said this assumption is a bit extreme, this application has as well some open redirector and http://localhost?goto=http://evil.com redirect to evil.com<http://evil.com> Well you can do your maths now and see that having a consent screen now would prevent such a threat For the record some less popular custom redirect uri used for mobile I have seen is also data: so also this might be “at risk" regards antonio On Jul 24, 2015, at 1:16 PM, Paul Madsen <paul.mad...@gmail.com<mailto:paul.mad...@gmail.com>> wrote: Antonio, are you arguing for short token lifetimes and so frequent explicit consent ? or something more if the app has a valid refresh token then there is no opportunity for the AS to inject a consent screen paul On 7/24/15 3:00 AM, Antonio Sanso wrote: hi, nice to see some work on this topic by the way! Couple of comments below inline On Jul 24, 2015, at 7:51 AM, John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote: 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. Is there any example of “popular” custom scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob Another common redirect_uri for native app I have seen is http://localhost<http://localhost/> One more comment. I strongly suggest for mobile app to have a really strict consent screen policy. Aka the authorization server MUST show the consent screen at every usage and not remember the fact that the app has been already authorized. Just my 2 cents :) regards antonio 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<mailto: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 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
