BTW, as I'm working it into the document, these are all great reasons to
recommend client authentication, but not to require it. You should clearly
require it if you are going to implement all these protections, but at the same
time, we clearly have use cases (pretty much from every major provid
Very helpful.
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Thursday, June 16, 2011 8:38 AM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>> wrote
Fantastic!
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Wednesday, July 06, 2011 9:11 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Example tokens
> Are the tokens used in the examples long enough? I don't want the examples to
> demonstrate poor choice of byte count.
N
> Are the tokens used in the examples long enough? I don't want the examples
to demonstrate poor choice of byte count.
No.
I found the following example values in draft 16.
Client secret: gX1fBat3bV (10 chars, 60 bits)
Code: i1WsRn1uB1 (10 chars, 60
Yes, I think it would apply to all three (in cases where the value is
some reference). I feel like a refresh token should be a little
longer but I don't know if that feeling would actually hold up when
doing a real threat model analysis.
On Wed, Jul 6, 2011 at 9:53 PM, Eran Hammer-Lahav wrote:
>
Does that apply to access tokens, refresh tokens, and authorization codes? I
can try squeezing in 22 characters.
EHL
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> Sent: Wednesday, July 06, 2011 8:46 PM
> To: Oleg Gryb
> Cc: Eran Hammer-Lahav; OAuth WG
So on the 128-bit note, the examples could probably be a bit shorter,
22 characters would give somewhat more than 128 bits of randomness.
But to EHL's original question, the examples (currently 7-12
characters) should probably be longer.
On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb wrote:
> log2(64^
What triggers this flow? If you are using the authorization endpoint with a
different response_type, it would be helpful if you shared that with the wg as
currently, that's simply not allowed (the values are not extensible). I am
going to change that in -17, but based on the requirement presente
I'm going to add text warning about third-party scripts included on the
redirection URI endpoint.
The right solution here is to make sure no script is executed before the client
code gets hold of the access token and hides it. Ideally, the landing page does
not include any third party scripts,
These are all good ways to mitigate the issue, but they don't solve it. If you
are running third-party scripts on the redirection URI page, all bets are off
as to who is going to end up with the access token, authorization code, etc. It
is pretty bad security to run any kind of third party code
log2(64^27)=162 bits
Looks good. For comparison, 128-bit entropy for a key in symmetric encryption
used by SSL is considered as strong.
I'm assuming that all those 162 bits are generated by a good randomizer.
- Original Message
> From: Brian Campbell
> To: Eran Hammer-Lahav
> Cc: O
If I've done the math correctly, 27 characters would give you a little
more than 20 bytes worth of randomness (assuming your are using random
alphanumeric characters or base64url encoded bytes). 20 bytes is
something you see as a SHOULD type minimum length in other protocols
for random identifiers
From: Shane Weeden mailto:swee...@au1.ibm.com>>
Date: Tue, 5 Jul 2011 13:24:36 –0700
6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization
Request
To protect against CSRF I believe the state parameter should be REQUIRED,
unless someone can demonstrate a scenario where it is no
I assume you are referencing 4.3.2? I think of that as a normal flow that not
specific to native applications. What is pointed out here is the authorization
code grant flow and the case you point out is covered in 1.4.3
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, June 2
Are the tokens used in the examples long enough? I don't want the examples to
demonstrate poor choice of byte count.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>
> - give out authorization codes via the user-agent flow. We've
> implemented a variation of this based on HTML5 and window.postMessage.
>
Caveat: This will run you off-spec.
> - use a fixed callback URL for the user-agent flow. Make sure that
> fixed callback URL does not run random bits o
On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer wrote:
> You can still use the access code (web server) flow within a JavaScript
> application, just without a reliable client secret. The point of the
> "implicit" flow was to save a roundtrip to the server for light clients
> with limited lifespans,
Correct me if i'm wrong, this case is handled by the nonce and time-stamp
values ?
On 6 July 2011 22:31, Justin Richer wrote:
> You can still use the access code (web server) flow within a JavaScript
> application, just without a reliable client secret. The point of the
> "implicit" flow was to
You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light clients
with limited lifespans, and it's a tradeoff between security, ease of
implementation,
Hello!
Foursquare recently encountered a scary example of a client accidentally
leaking user tokens as part of the implicit grant flow. It turns out the
official "Tweet this" button provided by twitter grabs the URL, including
fragment, at the time of page load, before the client's Javascript has
Reworded to modify the text around secret and some additional info on
redirect-uri (with some input from Shane Weaden) and adding state in
dynamic redirect-uri (with input from Torsten)
CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user t
Hi Eran,
I would suggest to change it to SHOULD and add a reference to
https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and
5.2.3.
regards,
Torsten.
Eran Hammer-Lahav schrieb:
It's a pointless MUST given how undefined the requirements are. It will only be
unders
22 matches
Mail list logo
