I propose adding the following section to the OAuth Security BCP specification:
Usage of CORS
The Token Endpoint,
Authorization Server Metadata Endpoint,
jwks_uri Endpoint,
Dynamic Client Registration Endpoint,
and any other en
Thanks - will do.
From: Mark Nottingham
Sent: Tuesday, March 7, 2023 7:55:29 PM
To: Mike Jones
Cc: Brian Campbell ; Amanda Baber via RT
; oauth@ietf.org ; Roy
Fielding
Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop
(http-field
Dear Yannick,
1. I agree with Neil and Hans. It's one hardened endpoint vs any other
endpoint which may have inadvertent security issues. It substantially
increases the attack surface.
2. Karsten has given a detailed explanation on the use of "state"
parameters. However in my opinion this design
Hi Mike,
Thanks. I left a comment on the PR, suggesting two small tweaks.
Cheers,
> On 8 Mar 2023, at 2:33 pm, Mike Jones
> wrote:
>
> Hi Mark,
>
> I've created the pull request
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your
> suggestions. Please also see some ad
Hi Mark,
I've created the pull request https://github.com/danielfett/draft-dpop/pull/180
to incorporate your suggestions. Please also see some additional replies
below, which are prefixed by "Mike>".
Please let us know if you'd like to see any changes to the PR before we merge
it and publish
The benefit of not storing the state of all users on the server-side is
still present. The client only needs to store and use *one *key-pair for
all JWTs.
On 07.03.2023 15:57, Yannick Majoros wrote:
I'm still missing the point:
- any key used to sign or encrypt the state... is state itself
- i
But what would encrypt or sign that redirect information? How will we
decrypt/validate it after redirection from the auth server?
1. The client takes the page from which the login was triggered, stores
it in a JWT, signs the JWT using a private key stored on the client.
2. The client redirect
I'm still missing the point:
- any key used to sign or encrypt the state... is state itself
- if we can store that key (or anything, like an url to go back to after
login), why bother passing the state around?
Le mar. 7 mars 2023 à 15:07, Hannes Tschofenig
a écrit :
> Hi Yannick,
>
>
> Am 07.03
Hi Yannick,
Am 07.03.2023 um 14:25 schrieb Yannick Majoros:
One possible solution: Store the redirect information in a signed JWT
and place the JWT in the state parameter. I don't think this is
written somewhere in the security BCP but I think this is a solutions
used in the wild by multiple cl
But what would encrypt or sign that redirect information? How will we
decrypt/validate it after redirection from the auth server? If the key is
stored somewhere (browser storage, backend, whatever), then no need to pass
that state information anyway. And we're back to our first problem: why
would m
I very much agree with Neil here, sending the authorization code to
application URLs is a recipe for leaking that code through the Referer
header to any remote site that content is loaded from (JS, analytics,
images etc. etc.). In addition to the inherent risk of "sloppy" pattern
matching, underes
On 6 Mar 2023, at 17:10, Yannick Majoros wrote:
>
> Hello,
>
> From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards in
> redirect_uri . Now, a common requirement for a portal or company-wide
> website, where multiple applications are deployed, is to be able to login and
>
Dear Yannick,
1. You have brought out a very valid design issue. I think it is a
good design imperative to land back on the same webpage from where we
started the oauth process. While there are various ways to handle this
problem at the application level, why should we do the same in custom
ways,
- In a context where all redirect URIs are under our control, how is
passing state and validating it back after login better, from a
security point of view, than validating redirect uri in the routing
implementation of the application? Both sound equally secure to me,
though redirect_uri seems
14 matches
Mail list logo
