I agree that stating "Clients in possession of a client password MAY
use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1]
implies that authorization servers MUST support HTTP basic
authentication, but such is never asserted. Instead, it says "The
authorization server MAY accept any
Is this a security issue in the OAuth2 process then (for mobile apps using
the authorization code flow)?
1. The draft says that mobile apps should be considered public clients
because mobile apps can be decompiled and can not keep their credentials
private.
2. In this case then, the draft says for
Hi Dave,
redirect URI validation does not authenticate a client. For example, a
URI registered for a private web client could be used by a (malicious)
native app to assume the web app's identity. The client secret, in
contrast, can be used to authenticate it.
regards,
Torsten.
Am 14.09.2011
Thanks for the follow up, Torsten.
Whilst I have your attention - any thoughts on my second question,
about the use of a client secret?
If for all clients we mandated registered URIs and verified them
(whether they are private and public), what additional security does
the client secret actually p
ok
regards,
Torsten.
On Wed, 14 Sep 2011 07:30:56 -0700, Eran Hammer-Lahav wrote:
I suggest we address this particular scenario in the thread model
document.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, September 14, 2011 7:26 AM
I suggest we address this particular scenario in the thread model document.
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Wednesday, September 14, 2011 7:26 AM
> To: Eran Hammer-Lahav
> Cc: Niv Steingarten; oauth@ietf.org
> Subject: RE: [OAU
ok with me.
On Sun, 4 Sep 2011 15:13:01 -0700, Eran Hammer-Lahav wrote:
That's not complete. A valid redirection URI is not enough to verify
client identity at the time it is presented, but it is enough in many
cases to prevent leaking credentials later on.
How about a slight change:
It is a native app and it is external wrt the browser.
regards,
Torsten.
On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote:
Is this malicious piece of software external a native application
either past of a native client or external to the browser?
EHL
-Original Message-
Fr
Hi Dave,
On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:
1. "The user does not have to be present."
Maybe I should be more clear. What benefit does that have over just a
long-lived (forever) access token? The cost is the extra complication
for
3rd party developers to have to worry ab
I have no objection, but "much clearer"? :-)
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Justin Richer
> Sent: Wednesday, September 14, 2011 6:04 AM
> To: Greg Brail
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Nit: Language in
Is this malicious piece of software external a native application either past
of a native client or external to the browser?
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Wednesday, September 14, 2011 6:51 AM
> To: Eran Hammer-Lahav
> Cc: N
Hi Eran,
As far as I understood, in a textbook CSRF attack the attacker would
create
his own requests in order to abuse a user's session. This can be
prevented by
utilizing standard CSRF coutermeasures (page token, nounce,
signature as
parameter on every request URL), which bind URLs to a cert
+1, this wording is much clearer to me, too
-- justin
On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote:
> This part of section 1.1 is confusing to me and I stumble whenever I
> read it – I see that Brian Eaton suggested looking at it a while back
> but I don’t think it got changed:
>
>
>
This part of section 1.1 is confusing to me and I stumble whenever I read it
– I see that Brian Eaton suggested looking at it a while back but I don’t
think it got changed:
“OAuth includes four roles working together to grant and provide
access to protected resources - access restricted reso
I would like to add my support to the comments below on section 2.3,
specifically 2.3.1.
It is clear to me from reading section 2.3 that clients MAY use HTTP
basic, or they MAY include client_id and client_secret in the request
body -- however, the latter is not recommended.
It is not clear what
15 matches
Mail list logo
