Gaining an understanding of Session Cookies and JWT Token

If you are using graphql you don’t need axios, you can use apollo to send directly the graphql api to the frontend.

A naive implementation of this I have here GitHub - wolfiton/medium_graphql_api at develop · GitHub.

It uses guardian and Absinthe context to set the token for the login mutation.

This project is under MIT and will be available fully after I finish it with the help of others.

In this branch i don’t have the apollo part but it should be available here GitHub - wolfiton/medium_graphql_api at tao_branch · GitHub

Also the frontend is not react but quasar which is a vue based framework something like preact, but much more.

Hope this helps

Hello @wolfiton Thanks for replying and showing an example with what you are currently building. After checking your github, I noticed my files are exactly the same in regards to the approach except two things.

First, for me when I do Guardian.decode_and_verify(token) I get in return an error related to the function saying it requires decode_and_verify/4 same for signing. Was there something done to avoid the approach of having to write Guardian.decode_and_verify(MyApp.Guardian, token)

Second, I was planning to use Apollo and actually did not know with Apollo we wouldn’t need Axios. (I haven’t gotten to the frontend yet, but thank you for that heads up). With that in mind, I’m still a bit confused in regards to JWT_Token and it’s existent.

As I mentioned earlier, when context.ex runs, it does right from the beginning where technically the header should fail as a token shouldn’t exist. But I don’t see the token being saved anywhere but instead it is being returned.

Question - how does this work
1 - Hit sign up user (meaning a token doesn’t exist for them)
2 - Before it hits the method, context would run meaning since it can’t find a header token it’ll return %{}
3 - sign up method runs which should create then sign out user returning user and token

What I don’t get is how do we use token for authenticating? I don’t notice us saving it ever during the entire flow and I’m wonder when we return token do we save that to Apollo? is that how we are using token to authenticate when making a request?

Again thanks for the help in understanding and really appreciate the GitHub project you send. Really will help in understanding where my approach was wrong.

Glad I could help you,

So the JWT or JSON WEB TOKEN is saved in localstorage in the browser, but in my current implementation, I am not at that stage yet.

The token will have usually the following values issuer validity(exp) and user id.

• Issuer makes sure that the token was created by our backend
• validity(expiration time 1h 1m 1y) the time it takes to expire and becomes invalid
• userid - the id of the user that is logged in.

To understand better about auth I also asked some questions here and posted a video about json web tokens in post 3, you should watch that video because it explains JWT.

Also the talk is being help by a security expert at okta.

PS: If you are not using a lot of js in your app a better approach is to maybe use phoenix directly with html views.

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

Hello @wolfiton I just got home. First, I would like to say thank you for providing everything to me. Also the video in regards to Session Cookies vs JWT. It really was amazing to see from an expert why they still would advise to stick what has not been broken.

Although I’m still puzzled by the idea how so many companies decide to use JWT instead of pure cookie based. I even had friends tell me it should be something I should implement to improve a bit of security.

I got a question. Since I noticed your post you’ve been trying to find a way not to use JWT, is there a reason why you still continued after watching the video? or that is for a different project?

After i had some private discussions with different members of the forum they convinced me to try both auth ways.

So the project(Medium Clone) that I am doing, with the help of @FelisOrion and other members of the forum will be:to create 2 versions:

• one with JWT auth
• one with cookie auth

I considered that if you receive(help, guidance) something from a community like the one at elixir forum then you need to give something back to others.

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.

Thanks @victorolinasc for the reference, but I am building a SSR not a spa with PWA capabilities.

So from my point of view I would gladly just use encrypted cookies with expiration time of 1 day then deal with json web tokens that are vulnerable to xss no matter where you store them.

But all the major frontend frameworks support officially only the jwt implementation if you want a cookie one, you will need a lot of luck to find a tutorial or a reference how to do that. In most cases you will get a nice advice to give up or do it yourself, because cookies are not important and they don’t have time for this. So use JWT in loclaStorage because it is easy and secure. Which is evidently not easy or secure and the reject tokens need to go in a blacklist.

That is my experience with this topic

Also wanted to add that OSWAP doesn’t like JWT’s in general.

Also if there is interest at what i am trying to build let me know and I will create a separate thread with the idea and some simple documentation, even though right now i am trying to figure out the best practices to create the medium clone.

So for several days I will be busy reading learning and comparing the different option i have available to create this.

That’s to be expected as cookies with http only active are not readable to javascript. They’re only useful to the server, but not to any client side code. But the question is: Do you need authentication handling on the client side?