> That’s why I think code+pkce should be the recommendation of our
working group.
I am in favor of this recommendation for OAuth2 implementations.
On 11/25/18 12:32 PM, Torsten Lodderstedt wrote:
Hi all,
I would like to state again what the proposal of the authors of the Security
BCP is:
I would perhaps clarify this a little, as it’s not really CORS that is doing
the work here, but rather the same-origin policy (SOP) — which is actually
*relaxed* by CORS.
It is the fact that there is a non-safe header (Authorization) on the request
that triggers the SOP protections - and it
Hi Torsten, thanks it makes sense.
> Do you see a need to add this to the BCP?
Well, while you are on it this might be a good chance to include this IMHO. At
least it will be a pointer for a question that might pop up quite often.
Regards
antonio
From: Torsten Lodderstedt
Date: Monday,
Hi Antonio,
good point. I would assume most SPAs will be public clients. Even if a single
instance registers dynamically and obtains a secret, this secret can only be
used as kind of „same originator“ proof (much like PKCE). SPAs with a backend
can also make the backend a confidential client.
Yes. Token Binding enforces that only the right browser can send the
token; in this browser, CORS enforces that only the correct origin can
send the token.
Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt:
> Does this mean the RS effectively relies on the user agent to enforce the
> sender
Hi Torsten,
nice one. FWIW I am reallly happy to see this happening.
Quick question though. What is the recommendation about dealing with the client
secret in this situation?
regards
antonio
From: OAuth on behalf of Torsten Lodderstedt
Sent: Sunday,
