PCKE prevents a bad app from using the code when there's a collision in the custom scheme used for the redirect URI. However the same app could immediately issue a new authorization request with it's own PCKE parameters and (mostly) transparently get back a code that it can use. Having some user interaction via the browser helps mitigate that.
6.4 says that "tokens SHOULD NOT be issued to such [non-confidential] clients without user consent or interaction" so it's not strictly required. Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT RECOMMENDED are effectively synonymous On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura <sakim...@gmail.com> wrote: > Prompting is not necessarily is a good thing. > It is very context specific, so please do not make it required. > > Nat > > 2015-07-24 16:38 GMT+09:00 John Bradley <ve7...@ve7jtb.com>: > >> Hi Antonio, >> >> Thanks for the feedback. >> >> I agree that for non confidential clients, the user needs to be prompted. >> It might be fair to just confirm the grants rather than resetting them >> from defaults. >> >> I know some people are doing that, but I suspect that not everyone is. >> >> Good stuff. >> >> People should chime in with other things we need to consider. >> >> Thanks >> John B. >> >> On Jul 24, 2015, at 9:00 AM, Antonio Sanso <asa...@adobe.com> 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> 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 >> >> 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> >> 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 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> 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 >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
