How does Sanctum SPA authentication work exactly?

@martinbean thank you for your answer, however I still don't understand something. Why do I need decoding user, for example, in my SPA? My SPA's API is just route like any other, on same domain, so Laravel's session is being automatically passed via cookie, I don't need to help it.

As for the CSRF I also don't understand why they introduce an endpoint that returns the token. I need to check if the cookie returned by that endpoint actually works as CSRF protection or needs to be manually attached to the API requests (the docs say so). I prefer to render my CSRF token in my template and then read it from the <meta> tag, just like I would with a regular app. I guess this CSRF endpoint is meant to make the API more independent from SPA, but in my case, I don't care about that, as I won't use my API with other client apps.

Anyone?

@beartown You only need to use the CSRF feature of Sanctum if your authentication relies on session cookies (because session cookies are vulnerable to CSRF). If you are using the other method of authentication by Sanctum, which is through personalized access tokens, you can ignore CSRF.

@Maelfjord thank you for your reply. Do I need Sanctum for CSRF protection though? It works just fine without Sanctum too.

I also don't quite get it why I need CSRF protection when there are CORS and SameSite protection layers as well. I could just skip sending session cookie when my app is requested from different domain.

I'm personally not a fan of CSRF, because sometimes it causes problems. Imagine having a form open in one tab and then having your website opened in another tab, logging out and back in there. You will be unable to send your form from the first tab. Maybe I'm being too dramatic, but it happened to me several times.

@martinbean please take a look at my last post at the bottom.

@maxxd they are not logged out. They logged out and then logged in, but in another tab, so they are logged in. It works fine without CSRF.

@beartown without csrf you are opening up security problems.

https://owasp.org/www-community/attacks/csrf

@jlrdw sure, however this document was created before CORS and SameSite as I understand it. If the client allows to block cookie access in different ways, I'd like to learn why CSRF is still so important.

@beartown Because you never know what a user is going to click on.

@jlrdw and clicking on what exactly would make it insecure when we protest our app with CORS and SameSite?

And by the way, there is something wrong with this forums too (Safari, macOS). I need to ALWAYS refresh the site to post, otherwise it's submitting the form and the post is not published. I wonder if that't the problem with CSRF too.

@beartown

And by the way, there is something wrong with this forums too (Safari, macOS). I need to ALWAYS refresh the site to post, otherwise it's submitting the form and the post is not published. I wonder if that't the problem with CSRF too.

You need to let @jeffreyway know this through the support link or a post with the topic of feedback.

@beartown If you are doing an API only then you need to lookup and study CORS spoofing and how to take preventative measures. CORS is not security.

@beartown The user is logged out, though - you said so yourself. Sure, they logged out in a different tab but they're still logged out of the site. If you are working at a cafe with a login-protected form in one tab and and another login-protected page in another tab and you log out of the site on the second tab in order to go grab another cup of coffee, some rando should not be able to sit in your spot, switch back to the form tab, and submit whatever damaging or dangerous input they want to. You should be logged out. Especially in this day and age, data security is a serious matter and should be treated as such.

@maxxd but this is not how it works in old fashioned websites, however I see your point.

@maxxd I did some digging and studied carefully how CSRF actually works in Laravel. I like Laravel's implementation of it - it only gets created once, when the app is first launched (and thus the session is created) and placed in the session payload under the _token key. No matter if we log in and/or log out million times - the CSRF token stays the same. It makes a lot of sense to me, even though it could be considered less secure compared to regenerating it timely or on some Auth events.

Also, I realized that this Sanctum SPA docs assume that your frontend is actually not Laravel. It's interesting, for example, that all calling /sanctum/csrf-token API endpoint does, is returning an empty response (204). Seriously, nothing else. It's only meant to "boot" the Laravel app for you (so in case of SPA, it's API layer) to make the CSRF cookie available for further API calls. That's a big relief for me now that I understand how it works exactly.

So to sum it up, as I understand it now, if my app is SPA made of Laravel frontend and Laravel backend, I do NOT need Sanctum, because everything will be handled out of the box securely.

@beartown I suggest also see https://www.youtube.com/watch?v=JatpAUl6_5E

Concerning authorization.