Use HTTP verb in Service Provider request mapper

Fabien BERTEAU fabien.berteau at
Thu Oct 21 13:28:23 UTC 2021

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


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