Re: [OAUTH-WG] Authorization Request via back channel / direct communication?

[Lewis Adam-CAL022 <[e-mail]>]

Hi John,

"Most of OAuth is predicated on not sharing the users credential with the client, because clients are not trusted."

This is exactly my point.  I clearly understand the driving motivations for why OAuth was designed the way that it was.  I certainly would not want to give website-A my password to access my data on website-B.

But it seems that since OAuth was first envisioned, it has gained an incredible amount of momentum for use cases that it was not originally envisioned for.  As we all know, there is a dominant trend within the enterprise to move away from WS-*/SOAP/WS-Trust toward RESTful APIs ... and if REST is going to replace SOAP and OAuth/Connect is the preferred means by which to secure RESTful API calls, then it seems it would be useful to define some OAuth flows that are optimized for enterprise use cases, where the client and RS are under the same security domain.  When we sell our products to customers, we sell them the server and we sell them the client.  It's all very trusted.  Nobody thinks twice about entering the credentials into an Outlook client to authenticate to an exchange server.  WS-Trust was optimized for enterprise scenarios  and clients apps collected credentials and passed them to the STS in exchange for a SAML assertion via a simple RST/RSTR.  This is analogous to the RO credentials flow which communicates the password in the request and gets the token in the response.  But WS-Trust also defined other types that could be passed in the RST other than password tokens.

So I guess all I'm getting at is that if REST is to replace SOAP (in the enterprise) and OAuth/Connect is to be the endgame, then borrowing some of the design patterns from WS-* would seem beneficial.  Again, it's not that I can't do the whole "register a handler for a browser URI thing" ... but for enterprise use cases, it's a kludge.

Just my 2 cents.  It's free :)
adam

From: John Bradley [mailto:[e-mail]]
Sent: Friday, June 08, 2012 9:04 PM
To: Lewis Adam-CAL022
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication?

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth