You're right in that OAuth is optimized for the confidential clients case -- specifically, a client being a web server talking to another web server. But what you've just described, in a nutshell, is the assertion grant type:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-03 Which has been profile for both SAML and JWT assertions here: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04 And could be extended to house any number of stronger-auth circumstances and formats. I believe Google and Deutch Telekom are making wide use of this today (correct me if I'm remembering incorrectly). But I'll say that for many cases it's still best practice to use the code flow and go through a UI for one simple but subtle reason: a browser can take in an infinitely diverse set of user credentials and the UI can change at any time without making any changes to the native code. Say you've got an OAuth backed native app that everyone's using the code flow and a username and password for. Great, works, no problem. Then you decide that you're not doing un/pw anymore and everyone needs to have a second factor, or do a captcha, or any number of other little things when they sign in and use the app. These kinds of things are *easy* to add to a web server's login page, but much harder to deal with in a native app directly. Challenge response scenarios are *trivial* with a web page -- they're practically made for it. And extend this scenario further by saying that you'll now let people log into your service using OpenID or another distributed identity protocol. All of this is really easy for the web server at the AS to handle, and the native app through all of this needs to be none the wiser. And this is a Very Good Thing. Plus it also gets your app out of the business of ever having to see users credentials directly. Remember: when you're doing the Resource Owners Credentials Flow, you're basically doing a benevolent man in the middle attack. Sure it works, and it beats logging in directly as the user at all times, but only just so. We actually ran into exactly this kind of thing a few years ago with an app here. It went like this: * Dev team was building a native application to connect to a website that had several different auth mechanisms including a username/password authentication key (similar to the OAuth2 un/pw flow) and OAuth 1. * They went with the un/pw setup because they figured it was easier and their native app could just ask for the un/pw combination. * This all worked swimmingly in the dev environment with all the test accounts * They roll to the integration environment which, like the Production system, was protected by OpenID 2.0 and not a username/password. In fact, none of the users on the system -- including the developers themselves -- actually had anything resembling a local password. Their app was completely at a loss -- the users couldn't present anything to the app to log them in directly at all. * After some head scratching and scrambling, they switched the whole app setup to OAuth (again, 1.0a). Now they could use the same exact code in the dev, integration, and production environments. And it worked across all user sets, regardless of how they got in the front door. *And* it will continue to work when we eventually upgrade this same service to use OpenID Connect instead of OpenID 2.0 in the future. Hope this sheds some light on this, -- Justin On Jun 8, 2012, at 6:43 PM, Lewis Adam-CAL022 wrote: Hi, I have a historical question around front channel / back channel (direct) communications and Authorization Requests. Both the code-flow and implicit-flow utilize a front channel communication through the UA. This makes sense for the delegated credentials case (e.g. shutterfly accessing photos on facebook). I’m in the native app / client market, and the RO password credentials flow fits really well … expect it’s limited to passwords. I’ve been well educated (by lots of folks on this list) about the “best practices” to enable native clients to use the code flow, e.g. registering a custom callback URI and register my native app ass the handler for that URI. But … (and not knowing the history behind all this), it seems that OAuth was designed for confidential clients, and was “retro-fitted” to make native apps work. And it just feels a bit like a hack to me (albeit a workable one), the whole custom callback URI thing, to get it to work. The RO password credentials seems like a much better fit for native apps, since it has no need for the UA and can use back channel / direction communication to talk to the AS and obtain and access token. But that limits me to a password and eliminates any chance of strong authentication. It would seem more straight forward to define a back channel flow such that a native client could send off an authorization request with response=token (or id_token in the Connect case), respond to a challenge from the AS for authentication, and obtain a response containing the access_token / id_token and use it for its RESTful API communications with the RS/RP. This would enable strong authentication methods not possible using just RO passwords. Has anybody else ever expressed interest in such back channel calls between for native clients? Was it previously considered and dropped? Tx! adam _______________________________________________ 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
