This is a wide topic. Session Cookies and JWT tokens are not the same thing and though when we compare them only by their names we are not comparing the same thing.

Using session cookies for authentication is a good use case scenario of cookies if your backend server is a monolith or if you have some kind of API gateway that keeps and translates cookies into user_ids for other services and you are not using something like zero-trust network.

JWTs are more of a tool than a user authentication solution. It comes in 2 flavors: signed tokens (JWS) and encrypted tokens (JWE). Both have their use cases that almost always fall on the category of distributed trust, like all your servers need to verify the authenticity of a token and you won’t share a global cookie store because you would need to also share the cookie signing keys and so on.

So, in my personal opinion, use what makes more sense to you. If it is a simple single server just use a cookie session and you’re good. Remember to make your cookies https only (to avoid JS accessing those) and you should be fine.

When the time comes for a more complex authentication/authorization solution, look for different approaches. One of them might be JWTs which might be persisted but make sure to research first.

To answer one of your questions, the traditional way of passing authentication data in the standard HTTP specification is to use the reserved header name authorization. The value starts with the name of the authentication scheme (something like “Basic”, “Digest” or “Bearer”) and the value of it. See here for a better explanation.

When you use cookies, the frontend also sends them through headers, in this case, the COOKIE, header. See here again for a better explanation.

@wolfiton be careful when storing tokens on local storage! It is not best practice when dealing with tokens on the frontend. See here for reference.

The subject is very broad… I’ve explained before why I think JWTs are useful here and why they don’t necessarily compare to session cookies.

Just so people don’t get it wrong, OWASP has a dedicated session on JWT (using Java) and considerations one should take into account when using it for authentication (it is here). It also has many considerations for all other kinds of authentication. Even cookie based session management.

At the same time it advocates the use of OpenID Connect as a widely adopted specification for identity providers and that protocol uses JWTs a lot. As do OAuth. They are not meant for your use case. Your architecture is a very simple web app that a session cookie might be enough.

In any case, I think that associating JWTs with an authentication system is not correct. I think it is a tool that has use cases as diverse as ensuring a signing and encryption set of algorithms implemented in a wide variety of languages in a variety of libraries.

But just to reiterate: your use case is simple and an HTTP session cookie with any opaque id (shouldn’t be guessable by the frontend) with httpOnly flag set is good enough security (nothing is 100% safe anyway). For other cases with distributed services that won’t be enough in my humble opinion. Nonetheless, you shouldn’t start with an OAuth/OpenID server if you don’t really know you are going to need it.

Here is that function used in the plugs to set the context of absinthe medium_graphql_api/lib/medium_graphql_api_web/plugs/context.ex at develop · wolfiton/medium_graphql_api · GitHub

To get a better understanding on how this all works clone the repo and try to play with it.

Use the playground in graphiql to create and login users.

I also new to phoenix elixir and vue, maybe this tut could help you get a better idea of the whole project it was the inspiration for my current project https://www.youtube.com/watch?v=uoCFQu9gQHE&list=PLw7bfDlTRWbgiApK7X1bRKJJ03xoDU3hm