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
