To some extent it goes to the question of who do you trust. Most of OAuth is predicated on not sharing the users credential with the client, because clients are not trusted.
Your situation may be different if you control the device. If you are using multi factor authentication then using an embedded web view is probably your best option to allow for flexibility as authentication mechanisms change for users rather than coding them into the app directly. Using a embedded web view with a OTP is probably not a bad thing though in general we want to train users not to put there credentials into untrusted applications and sites. John B. On 2012-06-08, 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 > 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
