You are putting too much weight on the value of redirection URI registration.
Since the same problem exists between the user-agent script and the server-side
component used in the user-agent profile, anyone can imitate that flow. In most
cases, the redirection URI will simply include a script th
I agree with the installed client issue it cannot be solved. But for a
browser-based user-agent script, it's particularly dangerous to not solve
it, and I believe it can be solved. By forbidding unregistered redirect_uri
values to be included in the request for a direct access token, user agent
s
+1 for _
I don't find HTTP header names having dashes confusing, because they all
do.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Joseph Smarr
Sent: Friday, July 02, 2010 3:16 PM
To: Eran Hammer-Lahav
>> We don't think base64url will work, because the most common error we'll see
>> is that developers forget the "url" part and just do plain base64, and
>> that's not sufficient because the stock set includes +.
>
> I think forgetting to url-decode is more likely than doing the wrong base64
> e
Just remember that dashes are problematic for JavaScript, since oauth_token
is a valid variable name, but oauth-token is not. So unless you're sure this
will never be a problem, +1 to underscores everywhere. I know HTTP headers
normally use dash, but if you want to use dashes for headers and unders
There is nothing you can do to protect any non-server-based client from
imitating another client. All you can do is require the end-use to be present
when you cannot trust who the client is (assuming you trust the user to know
what they are doing). What providers need to do is understand this an
No, that's a really simple recipe for disaster.
Flickr kept opening up this security hole. They would allow
applications to get new tokens simply using their api key & secret and
a user's session cookies. If we assume that for a desktop user-agent
will expose its secrets then this is a really easy
On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott wrote:
> I guess as a minimum then, user-agent clients should never be issued access
> tokens without explicit user interaction? Otherwise every web site around
> will automatically know who I am on facebook and who my friends are as soon
> as I auth
I guess as a minimum then, user-agent clients should never be issued access
tokens without explicit user interaction? Otherwise every web site around
will automatically know who I am on facebook and who my friends are as soon
as I authorize the one client that is popular.
Or am I missing somethin
While I will not be able to join the upcoming OAuth meeting in Maastricht, I
would like to see the following output from the meeting:
- Complete review of the -10 draft (to be published next week ahead of the
meeting), similar to that of -05 from the interim meeting.
- Discussion of internationa
At the end of the day, there isn't much you can do about user-agent clients.
Even a registered redirection URI doesn't really help because that endpoint too
cannot authenticate the client.
EHL
From: Andrew Arnott [mailto:andrewarn...@gmail.com]
Sent: Friday, July 02, 2010 9:51 AM
To: Eran Hamme
Hi Hannes!
Great, no hurry. I've been trying to get a grip on where we are with
discovery, and timing for LC on Oauth 2.0.
Looking forward to seeing you in Maastricht!
-Dorothy
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Friday, July 02, 2010 9
Hi Peter,
No problem, that sounds good. I remember we had some good discussions
regarding the charter and I couldn't remember if the WG agreed at some point or
not, and the page may not have been updated.
I look forward to more discussion!
Best Regards,
Dorothy
-Original Message-
Fro
Hi Dorothy,
interesting that you mention this. I had spoken with Blaine last week about the
IETF meeting planning and we also had a chat about the need to have a new
charter.
We will need to get feedback from the working group members about the scope
because the initially envisioned steps do
Ah! Yes I'd missed the second scope parameter that web servers have the
opportunity to see. And your point makes sense.
Is this reduced scope on the access token, and the encouragement for a
registered redirect_uri, the only mitigations we have for this possible
attack?
Popular client app *A *i
On 7/2/10 9:45 AM, Gellert, Dorothy wrote:
> Hi Hannes and Blaine,
>
> Is it possible to get an updated charter before the next IETF? I
> noticed the milestones are from 2009.
>
> It would help understand the progress and goals of the WG!
Hi Dorothy,
You're right that a re-charter needs to be
Scope is specific to the access token, not the code. In fact, I expect some
providers to issue an access token with a lesser scope than that provided when
exchanging the authorization code later (which will include another scope).
This is because the authorization server can authenticate the cli
Scope is an optional feature of a protocol. The server is free to express the
granted scope in any way it deems appropriate (that is, omit it, include it as
requested by the client, specify another granted scope). No changes are
necessary.
EHL
> -Original Message-
> From: oauth-boun...
> If the response type is code-and-token, the authorization server adds the
> codeand state parameters to the redirection URI query component and the
> access_token, scope, and expires_in to the redirection URI fragment using
> theapplication/x-www-form-urlencoded format as defined by...
Since th
Hello Marius,
Thanks for your feedback regarding this issue.
You make a valid point, stating that the authorization server should only send
the scope if it differs from the requested one. However, I would like to
enclose two notes regarding that approach:
* If I understand the 09 draft correct
If the scopes granted by the authz server are exactly the ones
requested by the client then I don't see the need for the authz server
to send a scope parameter.
I think the authz server should send the scope parameter if the
granted scopes are different from the requested ones, or if there was
no
Good afternoon,
We're in the process of implementing an open-source Ruby OAuth 2 (draft 09)
server, which will be made available at http://github.com/aflatter/oauth2-ruby.
During our draft 09 analysis we've noticed that the OPTIONAL scope sent by the
client in the Authorization Request is disco
Hi Hannes and Blaine,
Is it possible to get an updated charter before the next IETF? I
noticed the milestones are from 2009.
It would help understand the progress and goals of the WG!
Thanks,
Dorothy
___
OAuth mailing list
OAuth@ietf.org
h
Hi Rob,
I agree with you that a migration spec is important - please write one.
As for every provider returning the same error code, I don't think that this
will always be the case as some providers will return invalid-request on other
security related errors to reduce the amount of information
Eran Hammer-Lahav wrote:
[Replying to everything at once...]
-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 11:43 AM
Exactly. While it might be needed in the future, there is a need to
differentiate OAuth 1.0 from 2.0 on
25 matches
Mail list logo
