Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

[Torsten Lodderstedt <[e-mail]>]

good question!

I see two strategies:

a) HTTP Authn Schemes are used for client authn only, this would require 
to pass user credentials as API parameters in  "Username and Password Flow"
b) like (a) except user credentials for "Username and Password Flow" are 
passed in as Authorization Header. The Benefit: applications currently 
using BASIC/DIGEST authentication can easily migrate since authn does 
not have to be changed. I see the "Username and Password Flow" primarily 
as a migration flow (as stated in 3.6.1). So an exception would be 
legitimated from my point of view. Moreover the spec could explictly 
recommend to move implementation to other flows, like web or device.

regards,
Torsten.

Am 17.04.2010 13:42, schrieb Eran Hammer-Lahav:
> How would use differentiate between the username and password profile 
> and the client credentials profile, if you are using Basic or Digest?
>
> EHL
>
>
> On 4/17/10 1:10 AM, "Torsten Lodderstedt" <[e-mail]> wrote:
>
>     I support the idea to use standard HTTP auth mechanisms for
>     authentication on the authorization server endpoint. From a design
>     standpoint this is just an API - which we cannot to protect via
>     OAuth tokens because it issues these tokens. But we can use HTTP
>     standard authorization mechanisms (and headers) as BASIC or DIGEST
>     to authenticate the callers. This gives implementations the option
>     to use other mechanisms (like SPNEGO or CERT). And as James
>     pointed out, there might (will in our case) other requests on this
>     endpoint used to provide additional services via other HTTP
>     methods, e.g. DELETE. Moreover, standard authn modules (as in
>     HTTPClient) can directly be used to implement access to OAuth
>     authorization servers.
>
>     I would recommend to separate functional API parameters, like
>     callback url, and authorization data.
>
>     regards,
>     Torsten.
>
>     Am 17.04.2010 06:52, schrieb Manger, James H:
>
>           Re: [OAUTH-WG] Issue: Split the authorization endpoint into
>         two endpoints
>
>
>         > This has nothing to do with it. There is no PUT and DELETE or
>         POST with non-form body when *requesting a token**.
>
>
>         *
>         It is relevant.
>
>         I don't want to authenticate direct client requests **only**
>         when they **request a token**.
>
>         Clients might make any variety of direct requests unrelated to
>         OAuth.
>
>         There might even be other OAuth-related requests from clients
>         to an authorization server in future (eg get meta data, or
>         delete a token; even refreshing a token might be better as a GET).
>
>         I want to be able to use the same client auth mechanism, and
>         same client credentials, for all these calls.
>
>         Some of these calls might be PUTs, DELETEs, non-form POSTs,
>         GETs etc. even if requesting (& refreshing) a token is always
>         a form POST.
>
>         Hence client_secret as a POST parameter when requesting a
>         token is a poor design.
>
>
>
>
>
>         It should be perfectly valid (and not uncommon I expect) for a
>         service to support OAuth for user delegation, but not use
>         OAuth for making all direct client calls token-based --- these
>         address quite different issues.
>
>         Other services might use short-term refreshable tokens when
>         clients (on their own behalf) access less trusted "content"
>         service, but will use "normal" auth when clients talk to the
>         trusted account/authorization system.
>
>
>
>