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

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 8 Jun 2012 22:43:19 +0000

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Sat, 9 Jun 2012 01:00:44 +0000

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’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.

Tx!
adam
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Jun 2012 22:03:45 -0400

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:

> [email-masked]

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Sat, 9 Jun 2012 22:08:01 +0000

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:[email-masked]]
Sent: Friday, June 08, 2012 9:04 PM
To: Lewis Adam-CAL022
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication?

John B.

Hi,

Tx!
adam

---

From: Chuck Mortimore <[email-masked]>
Date: Sat, 9 Jun 2012 20:19:19 -0700

Hey Adam...

There's been a bunch of work done adapting OAuth to enterprise use-cases.    Check out the oauth assertions draft and the saml and jwt bindings.   In addition, a number of deployments have established strong patterns for using the more common flows in enterprise settings.   I'd be happy to discuss if you're interested.

- cmort

On Jun 9, 2012, at 3:08 PM, "Lewis Adam-CAL022" <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

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

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:[email-masked]]
Sent: Friday, June 08, 2012 9:04 PM
To: Lewis Adam-CAL022
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication?

John B.

Hi,

Tx!
adam