Is something as the user agent flow used in the wild today? What
security means are used their?
I wonder why we do not drop the user agent flow from the spec because of
security reasons. From my point of view, the web flow could be used to
achieve a similar behavior except the JavaScript
Eran Hammer-Lahav wrote:
Hi Rob,
I agree with you that a migration spec is important - please write one.
Like I didn't see that coming :)
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
The user agent flow is really useful if you just require user
interaction to issue new access tokens. There are big benefits
(including security benefits[*]) to not involving the server.
Ian
[*] the security benefit being that I never have had to authorize your
server to do action on my behalf,
On Jul 3, 2010, at 3:19 AM, Torsten Lodderstedt wrote:
Is something as the user agent flow used in the wild today? What security
means are used their?
Yes. Facebook has shipped it:
http://developers.facebook.com/docs/authentication/desktop
We require either pre-registration of the callback
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
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
On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
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
Let's not lose sight of the underlying reason to choose base64:
avoiding the issue of canonicalisation. If you use an encoding that
various software layers can choose to decode and operate on, then you
open the canonicalisation can of worms. The point of using base64 is
so the blob you hand around
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s in the token, then it is easy for someone helping to spot
the problem. also easy for servers to send back an error message
On 2010-07-03, at 11:28 AM, Luke Shepard wrote:
* We'd like the signature first (so you can left split instead of right
split)
What are the advantages of left split vs right split?
Built in split function with a limit is more common, which makes the left
split easier.
Size
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
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
(this sounds sarcastic, but I'm no being sarcastic... it's a serious
question/challenge)...
Why not just remove the client_id parameter from the user-agent flow? It's
absolutely meaningless to security. It's only perceivable benefit is that
the auth server can possible display to the user the
On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s
Section 4.1.1, which deals with requesting an access token using an
authorization code, doesn't list the client_id and client_secret parameters
at all, yet mentions verifying them in paragraph form, and they are included
in the example.
--
Andrew Arnott
I [may] not agree with what you have to
Hello,
Both examples in section 2.1 mention a type parameter, which, if I'm
interpreting the changes correctly, has been removed in -07.
Assuming it's indeed a typo. Where it reads:
For example (line breaks are for display purposes only):
POST /token HTTP/1.1
Host:
I see an invalid-client-credentials error code, but for the
basic-credentials grant type, it seems there should be a specific error code
to indicate the resource owner's basic creds are invalid, as opposed to the
client's credentials being invalid.
--
Andrew Arnott
I [may] not agree with what you
Thanks. This was previously reported and already fixed for -10. Should include
the grant_type parameter.
EHL
On 7/3/10 3:57 PM, Diogo Almeida diogo.borges.alme...@gmail.com wrote:
Hello,
Both examples in section 2.1 mention a type parameter, which, if I'm
interpreting the changes correctly,
Section 2 talked about how the client authenticates itself. This is used in the
token endpoint but can be used elsewhere (i.e. A device profile).
EHL
On 7/3/10 5:42 PM, Andrew Arnott andrewarn...@gmail.com wrote:
It may be my misreading the spec, or making assumptions based on my cluttered
There is no difference. The client credentials are either valid or not.
EHL
On 7/3/10 5:28 PM, Andrew Arnott andrewarn...@gmail.com wrote:
I see an invalid-client-credentials error code, but for the basic-credentials
grant type, it seems there should be a specific error code to indicate the
18 matches
Mail list logo
