Use HTTP verb in Service Provider request mapper

[Fabien BERTEAU]

if you are interested:
https://medium.com/@fabien.berteau/why-we-should-no-longer-use-bearer-tokens-to-protect-sensitive-single-page-applications-a7597c6c3097


Fabien Berteau | Security Architect

Bordeaux

fabien.berteau at manomano.com <aurelien.lajoie at manomano.com>


Le jeu. 21 oct. 2021 à 15:28, Fabien BERTEAU <fabien.berteau at manomano.com>
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 manomano.com <aurelien.lajoie at manomano.com>
>
>
> Le jeu. 21 oct. 2021 à 15:18, Cantor, Scott <cantor.2 at osu.edu> a écrit :
>
>> On 10/21/21, 9:11 AM, "users on behalf of Fabien BERTEAU" <
>> users-bounces at shibboleth.net on behalf of fabien.berteau at manomano.com>
>> 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
>> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20211021/7bec7f9e/attachment.htm>