would you please outline a example?
Am 08.04.2010 18:38, schrieb David Recordon:
Agreed with Eran. GET parameters certainly make exploring APIs easier.
On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav<[email protected]> wrote:
While I agree that the spec would be much cleaner with only HTTP header
support, and have tried that approach before, in practice it will cause
significant adoption problems.
I rather add support for query and post parameters (we are really talking
about a single parameter, oauth_token, outside the HTTP header), and in a
few year deprecate it in OAuth 3.0. The benefit of these features is that
they allow existing browsers to deploy OAuth *today*.
As for the document structure, it is too early to tell. With OAuth 1.0a I
ended shuffling the sections in draft -09... The spec has to tell a story.
EHL
On 4/8/10 1:54 AM, "Torsten Lodderstedt"<[email protected]> wrote:
Hi Eran,
since you are re-working sections 5-7 now, I want to address some
general issues I see there.
- What is the benefit of including "URI Query Parameter" and
"Form-Encoded Body Parameter" in the standard? I see OAuth as an HTTP
authentication scheme similar to BASIC or SPNEGO. All of these schemes
exclusively use Authorization headers for sending credentials from
clients to servers. That way, authorization is kept orthogonal from
the servers API.
Advantages:
+ APIs can be combined with different authentication schemes
+ Libraries can be plugged in and easily add authorization data
+ no name clashes with API parameters
+ can be combined with any HTTP method
It's ok with me if someone wants to send tokens as Query/Body
Parameters. But then the token parameter becomes a part of the
resource servers API. Why standardizing that?
From a security standpoint, sending tokens as query parameter is
problematic since their are many ways to leak them. Servers typically
log target URLs in default configurations, GET request URLs are stored
in browser caches and proxies. And what about Referer-Headers?
When we adopted OAuth 1.0a, the fact that OAuth 1.0a supported three
different ways of sending tokens caused a lot of confusion. What type
is supported by what resource server? Do we need to support all of
them or a sub set? e.t.c.
So IMHO removing 5.1.2 and 5.1.3 would make the standard much simpler
and easier to understand/implement/use.
Moreover, it should save at least 2 pages.
- I would like to suggest to change section ordering (5-7) in order to
facilitate readability. From my point of view, the major contribution
of the OAuth HTTP authentication scheme is the definition of the
Authorization headers syntax (and semantics). Why not putting this in
front? Further on, the natural counter part of the Authorization
header is the WWW-Authenticate header since it is used to advertise
important properties of the authentication scheme to clients. So I
would suggest to describe it afterwards.
Based on this considerations, I would suggest the following structure
(just a sketch):
4 (was 7) Authorization Header
description of both variants
token only
token + signature
5.2.1 Computing the signature
security considerations
e.g. implementations MUST support bearer tokens w/ HTTPS, resource
servers and clients SHOULD use it
5 (was 6) WWW-Authenticate Header
I'm willed to contribute a more elaborated proposal if you and the WG
agree with the direction I proposed.
What do you think?
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
