Use HTTP verb in Service Provider request mapper

Fabien BERTEAU fabien.berteau at
Thu Oct 21 13:39:10 UTC 2021

if you are interested:

Fabien Berteau | Security Architect


fabien.berteau at <aurelien.lajoie at>

Le jeu. 21 oct. 2021 à 15:28, Fabien BERTEAU <fabien.berteau at>
a écrit :

> I too am against the concept of SPA but after a long stint in the world of
> education where SAML reigns supreme, here I am in an online commerce
> company where many young people only know JavaScript, SPA, React, web and
> OIDC services.
> I have no choice but to adapt but we are coming to the limits of this
> technology and that's where I say to myself: why not SAML?
> The main reason why I do not agree with the very principles of OIDC is
> that the access token is a bearer security.
> Anyone who captures it can use it as its rightful owner. And no OIDC
> protocol protects these tokens from an XSS-type attack.
> However, our hackers have assessed that the risk incurred by our company
> has become too great with this technology and forces us to no longer store
> these tokens in a context reachable by an XSS-type attack.
> If the session cookie is HTTP only and secure, then it is out of scope and
> should be automatically loaded by the browser when it is called via its
> XMLHTTPRequest interface.
> Fabien Berteau | Security Architect
> Bordeaux
> fabien.berteau at <aurelien.lajoie at>
> Le jeu. 21 oct. 2021 à 15:18, Cantor, Scott <cantor.2 at> a écrit :
>> On 10/21/21, 9:11 AM, "users on behalf of Fabien BERTEAU" <
>> users-bounces at on behalf of fabien.berteau at>
>> wrote:
>> >    This answer scares me because we already use OIDC but we realize
>> that it is not enough.
>> I'm not saying it's secure, I haven't studied any of it. I got off this
>> train a lot of stops back when it became clear I did not have a compatible
>> worldview to deal with it.
>> > To overcome this, we use a reverse proxy overlay (NextAuth) to make our
>> OIDC authorization server believe
>> > that we are still in Authorization Code flow. But this results in an
>> overly complex system which I think could be
>> > simplified with SAML. If you yourself are against the use of SAML in
>> this increasingly widespread use case,
>> > then I am afraid of us :)
>> I'm not against the use of SAML if you think it's what you want, I'm
>> simply against the concept of a SPA and I am not sorry or sad that people
>> think SAML doesn't work well with them. To me that suggests we got it
>> pretty right.
>> In the end though, I'm not sure what the difference is between a code
>> being accessible to javascript and making a session cookie accessible to
>> it. Same thing, isn't it?
>> -- Scott
>> --
>> For Consortium Member technical support, see
>> To unsubscribe from this list send an email to
>> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list