Cookies vs token for authentication

You can keep a users session logged in by putting their cookies into the browser .
But what about if youre using token based authentication instead and the users browser doesn't allow cookies ? How do you store a session at that point?

There are few options.

The first one is to embed session ID to your URLs. Some frameworks do that, but I won't recommend this approach for obvious reason of security. Another option is to add session ID to the header of each HTTP call on application level.

In other words, after client side of your application receives session token from the server, it will have to append it to each further request back to the server. Frankly, in this case you will have to implement cookie functionality by yourself. Session ID could be included to HTTP header or API params. Both options are better than embedding it to URL.

Major difference between this approach and normal cookies is that the app-level session will be terminated after user close the browser. Because you don't have a chance to persist session ID (if I understand the situation correctly).

To be honest, I won't recommend this approach either, regardless it is technically possible. Random bug in the implementation could cause major vulnerability.

Well, that brings up another question.

Let's say you set it up a way to store a cookie where cookiename = "johndoe".

With cookies in rails, you can easily grab whatever is inside cookiename by doing cookies[:cookiename]and get johndoe returned.

What about with tokens???

Typically people will store JSON Web Tokens in localStorage so they're persisted across requests in the browser. This has the (somewhat major) downside of tokens being stealable by any Javascript that runs on the page and why session cookies are still the right answer for 95%+ of apps. You're far less likely to screw up the security of sessions with the traditional approach.

Token authentication works best when you're using it for mobile apps because you aren't likely running anyone else's code. You can save the token in an encrypted place accessible only by the app using the native libraries and know your token is secure there. On the web, it's not so easy.

Here's some good food for thought on JWTs:

From this article: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

@chris Thanks for the resources and explanation! I'm using token based authentication on my iOS app which is of course connected to my rails backend (my friend developed the iOS , not me).

I should note that i'm basically trying to create intercom.io, so my 'api' would be installed in other websites and it needs to work nicely with CORS. It's just a<script> src="example.com/widget.js"</script>type.

Unfortunatetly, Safari doesn't allow you to store 3rd party cookies from an iframe unless the user has been to the iframe's origin domain. So, I THINK token based authentiation fixes this problem and maybe this is how intercom.io is overcoming this issue with tokens. And the authentication is very important, otherwise you can't keep track of which visitor you're having a conversation with on your website.

Also, I can return a cookie by doing<%= cookies[:username] %>, but how would one do this for tokens?

Possibly <%=request.headers["username"] %>???

EDIT 1: Regarding Safari, I think postMessage might be a possible solution to passing in a cookie to the parent domain and than passing that cookie to the iframe so that it can search for the user or whatever they wish? https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Thoughts?