Is there a way to have the frontend auto login the user to strapi if they already have the JWT stored in a cookie? Im trying to migrate from firebase and wondered if there was a similar/preferred way to handle the user auto-login feature that firebase provides?
Will be curious to see the response from our community on this, I know the cookie topic is a popular one.
Well, here are my thoughts on this:
- Strapi sends the jwt in response body, if connection is over ssl is secure enogh
- Strapi expect the token in
Authorizationheader, so changing this behaviour in backend IMHO should be avoided to keep things clean and to reduce the todo list on migrations, therefore sending the same jwt twice (in cookie + header) will make the http communication unnecessarily difficult.
Here comes the real challenge: where to store the jwt, and how to feed the
Authorization header only when is necessary?! How to share the token between browser windows (same domain) without storing it in a cookie?
Considering security is important to you, my conclusion so far is this:
- no store: not reliable IMHO, it causes too many http talks
- in local or session storage:not reliable, avoid it with all costs
- in global variable: not reliable, too many other security dependencies
- in session cookie: reliable, but as I described above it will add weight to each connection
- in local variable: reliable, but can’t be shared with other windows except the case a security vulnerability is introduced
So, the choose is between session cookie and local variable, I choose local variable by sacrificing the multi login (as does for example protonmail).
An easy way would be to provide
Authorization header to all api calls, but the public data doesn’t require it. In fact public data can be requested in over 80% of all cases. Here, some frontend frameworks and browsers have built-in mechanisms to provide
Authorization header on backend demand only, I wouldn’t use any one of them, again, because an extra connection is made. For this, it would be good for api url to be differentiable by a prefix indicating the necessary permissions, such as:
GET /api/public/posts GET /api/posts // with Authorization header
We can do this in the frontend, add the prefix in html and remove it in the api fetch function.
As far as I know Strapi doesn’t have any
preferred way to deal with login, Strapi just provides a 30 days valid token as described above and there is no login or logout (except administration panel). Sorry for not giving a direct answer to your question where you say the user already have the JWT stored in a cookie, by default Strapi does not store the JWT (it can’t because is not a frontend framework) and above I explained why I wouldn’t store the JWT in a cookie. Its just my opinion, I hope others will provide their opinion too… Anyway, having exact same type of concerns plus a bounch of other security concerns in mind I created my
strapi access proxy project (to reduce the validity of token for specific use cases, to customize the token, and so on…)