sounds good.
One question arose: OpenId has the same design challenge. There are
direct calls, like "associate", as well as indirect calls, like
"checkid_setup". OpenId uses a single endpoint on the OP and
differentiate the request types via the openid.mode parameter.
Does anyone know why OpenId want that way?
Am 16.04.2010 22:51, schrieb Eran Hammer-Lahav:
I'll split them to: Authorization endpoint and Toke endpoint. In the
WWW-Authenticate header I'll add a parameter for each (instead of one)
for lightweight discovery (which we can keep, change, or drop later).
EHL
On 4/15/10 6:22 PM, "James Manger" <james.h.man...@team.telstra.com>
wrote:
I strongly favour specifying 2 separate endpoints: one for where
to redirect a user, another for direct client calls.
I agree with Marius that these two endpoints are different enough
to be separate.
One is only used by users via browsers. The other is only used by
client apps. These are different populations, using different
authentication mechanisms, with different performance
requirements, and different technologies.
The use of a type parameter is a poor tool to distinguishes these
cases.
I guess 1 URI could default to the other if not defined.
1 URI could be allowed to be relative to the other to save some bytes.
--
James Manger
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into
two endpoints
OAuth 2.0 defines a single authorization endpoint with a 'type'
parameter
for the various flows and flow steps. There are two types of calls
made to
the authorization endpoint:
- Requests for Access - requests in which an end user interacts
with the
authorization server, granting client access.
- Requests for Token - requests in which the client uses a
verification code
or other credentials to obtain an access token. These requests require
SSL/TLS because they always result in the transmission of plaintext
credentials in the response and sometimes in the request.
A proposal has been made to define two separate endpoints due to the
different nature of these endpoints:
On 4/6/10 4:06 PM, "Marius Scurtescu" <mscurte...@google.com> wrote:
> Constraints for endpoints:
> access token URL: HTTPS and POST only, no user
> user authentication URL: HTTP or HTTPS, GET or POST,
authenticated user
>
> In many cases the above constraints can be enforced with
configuration
> that sits in front of the controllers implementing these endpoints.
> For example, Apache config can enforce SSL and POST. Same can be done
> in a Java filter. Also a Java filter can enforce that only
> authenticated users hit the endpoint, it can redirect to a login page
> if needed.
>
> By keeping two different endpoints all of the above is much simpler.
> Nothing prevents an authz server to collapse these two into one
> endpoint.
While requests for access do not require HTTPS, they should
because they
involve authenticating the end user. As for enforcing HTTP methods
(GET,
POST), this is simple to do both at the server configuration level or
application level.
On the other hand, having a single endpoint makes the
specification simpler,
and more importantly, makes discovery trivial as a 401 response
needs to
include a single endpoint for obtaining a token regardless of the
flow (some
flows use one, others two steps).
A richer discovery later can use LRDD on the single authorization
endpoint
to obtain an XRD describing the flows and UI options provided by
the server.
But this is outside our scope.
Proposal: No change. Keep the single authorization endpoint and
require
HTTPS for all requests.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
