Subject: [OAUTH-WG] Client Password Credentials

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Dec 2010 17:34:52 -0800

Currently there are two different ways a client can send credentials,
as specified in section 3.1, and:
"The authorization server MUST accept the client credentials using
both the request parameter, and the HTTP Basic authentication scheme."

I know there was a long thread on this subject, but I cannot recall
the reasoning. Can someone summarize it?

How many of the existing OAuth 2 server implementations out there
currently support both methods?

Thanks,
Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 5 Dec 2010 23:39:33 -0700

The argument was, since these are basic credentials, they should be used in the native HTTP method using the header. But since that is not as simple as a pair of parameters, we ended up with both. The easy way and the right way.

>From implementing it, my experience has been that it can be hard to deal with Basic in the context of another authentication class. Since OAuth and Basic are usually two classes provided by the same authentication layer, having one use the other can lead to tricky architecture. This trivial to implement in a clean environment, but a bit messy when adding to an existing framework.

I am split between doing what is right and what is practical here.

EHL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Thursday, December 02, 2010 5:35 PM
To: OAuth WG
Subject: [OAUTH-WG] Client Password Credentials

Currently there are two different ways a client can send credentials, as specified in section 3.1, and:
"The authorization server MUST accept the client credentials using both the request parameter, and the HTTP Basic authentication scheme."

I know there was a long thread on this subject, but I cannot recall the reasoning. Can someone summarize it?

How many of the existing OAuth 2 server implementations out there currently support both methods?

Thanks,
Marius
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Dec 2010 09:21:43 -0500

Is there a real downside to making them both optional with availability
specified by the AS? I have a feeling that's what we're going to end up
with in the wild anyway. That is to say, frameworks that can't dig deep
enough into HTTP to get to the Basic credentials just won't support that
method, even if the spec technically requires it.

 -- justin

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 6 Dec 2010 12:11:08 -0800

> The argument was, since these are basic credentials, they should be used in the native HTTP method using the header. But since that is not as simple as a pair of parameters, we ended up with both.…

Not sure why is native HTTP the right way. Just because they are basic
credentials? So is the username+password in the profile with the same
name.

> From implementing it, my experience has been that it can be hard to deal with Basic in the context of another authentication class. Since OAuth and Basic are usually two classes provided by the sam…

The other complication comes from the fact that the server has to send
an error response differently, based on how the credentials were sent.

I really don't see the point for all this complication.

I asked a few of the early OAuth 2 implementors, most don't implement
the HTTP method at all, one implements it but only for the sake of the
spec.

If most implementors do not find this feature useful then I think it
should be removed from core. Just to keep things simple. It can always
be added as an extension.

Marius