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
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
Hi Rodrigo,
Thanks for the link. I'm already familiar with that document, but maybe you
can point me to some part that I missed.
My questions are:
- 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
Hi Yannick,
There is a work-in-progress draft that touches many threats and best
practices when implementing OAuth 2 [
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/21/]. I
recommend that you read entire document, but, especially, about your
questions, you may understand the th
Hey Aaron,
Sure, this is some kind of open redirector. I had a similar example with
Uber. Still, those examples involve integrations with 3rd party
applications. It also seems to me that they either imply implicit flow, or
an authorization code not protected by PKCE. Aren't we mitigating these use
There is no situation in which supporting arbitrary redirects (whether from
the OAuth redirect URI or within your own app) is a good idea.
This is known as an Open Redirector, and is the basis of many attacks on
OAuth as well as other things unrelated to OAuth. OWASP has a cheat sheet
about this a
Thanks for your input.
All of that would be quite common indeed, but in what way is it better,
from a security perspective, than redirect URIs with wildcards?
Yannick
Le lun. 6 mars 2023 à 18:28, Vittorio Bertocci a
écrit :
> In my experience the most common solution, adopted by many SDKs, is
I have also seen what you describe in 2, as well as a variation of that,
which is to encode the redirect in the "state" parameter, as described
(briefly) in RFC6749 https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.2
Note that using "state" to carry this redirect should only be done with a
fixe
In my experience the most common solution, adopted by many SDKs, is based
on 2.
Where you redirect after you concluded the token acquisition ceremony is a
private consideration for your app, that shouldn’t interfere with how the
client is registered. Oauth offers you the chance to store and retriev
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 come back to the page from which the login was triggered.
How can
18 matches
Mail list logo
