JSON Web Tokens vs. Sessions • Hacker News Board

Re: JSON Web Tokens vs. Sessions

#171

Post by saynsedit » Wed, Jun 22, 2016, 7:58 AM UTC

jsmeaton wrote: post #170

saynsedit wrote: post #169

Earlier quoted context omitted.

It wasn't a personal attack. Computer security is a minefield of unknown unknowns. Individuals that aren't deeply familiar with all the modern attacks or aren't skeptical of unknown attacks shouldn't design crypto, has nothing to do with you. Some people need a document to tell them what the secure thing to do is, security analysts don't. I would beg anyone who claims that timing attacks against signatures don't exis…

It wasn't the "don't build security" that was the attack. It was "be a good boy and tell us who you are so we're protected from your incompetence" that I'm taking issue with. I think it's particularly unfair seeing as your original reply to me was so brief that I missed the crucial point. Anyhow, we're done here.

Asking you to disclose your identity was only a suggestion and it was offered at your discretion, appealing to your potential desire to be a Good Samaritan.

My sincere intent was not to offend you but protect you from yourself. I had already offered what I thought was sufficient explanation for the attack and I felt there were no further options.

I did not mean to offend you but since I have I apologize. I don't believe one's self-worth or employability is based on their expertise in computer security but I can see how that can be implied by what I wrote and I was wrong to be careless with my language online. Honestly I am no expert either. I just hope we can all cooperate, put our egos aside, remain humble in our limited knowledge, keep an open mind and stay focused on the facts to build more secure systems.

Peace and well wishes to you and your family.

Re: JSON Web Tokens vs. Sessions

#172

Post by jcoffland » Fri, Jun 24, 2016, 7:52 AM UTC

zimbatm wrote: post #155

jcoffland wrote: post #151

Earlier quoted context omitted.

Searching a revocation list misses the point of RESTful authentication.

There is no such thing as a RESTful authentication. REST's design hinges on URIs being public.

What do public URIs have to do with it? I don't think we are speaking the same language.

Re: JSON Web Tokens vs. Sessions

#173

Post by lobster_johnson » Sun, Jun 26, 2016, 8:53 PM UTC

DenisM wrote: post #163

lobster_johnson wrote: post #161

Earlier quoted context omitted.

It's an interesting idea, but that would mean every internal microservice request (they don't just service users) would have to go through an API gateway, and every call would have to be checked against a session store. It also means (if I understand the design correctly) that the API gateway has to munge every request envelope to add the actual user ID as an HTTP header (or something similar with gRPC), so that the…

The services are behind the firewall, unreachable from the internet, and only accept requests from the gateway, and from each other. The gateway strips your SSL (which I'm sure you are using :)), authenticates the request against its local security token store, then adds a bunch of headers: request id for tracing purposes, user IP for logging purposes, user id for authorizing access to various resources, etc. The ser…

You're right about the API gateway being a good pattern for sending external traffic to internal microservices, and it is something you'd want regardless of what session system you used.

I'd let microservices talk directly to each other, however, rather than going through the API gateway. This means you reserve the API gateway for external traffic, and trust the internal traffic. You still need to standardize on/configure a set of "context headers" to pass from one services to another so that the identity of the original caller is preserved; but since this won't rely on a session, it can be trusted and treated opaquely by each application.

My earlier point stands, though: Once you deploy something like this, you now have an explicit dependency on the API gateway, because services can never be directly exposed to the world. It impacts local development, too, because now you either talk using session via the API gateway (which you have to run locally) or directly to the service (using whatever identifying information it trusts), and the fact that they are different is a potential point of confusion, especially for someone not familiar with the architecture. ("It isn't working" — "Oh, you need to go through the API gateway.")

Interesting conversation indeed. I wish there were a better forum for such discussions. There's a lot about microservices where I'd love to exchange ideas and good patterns.