4 ms·
So, I've been approaching JWT as a "proof of login" essentially, to handle authentication across web, mobile apps. The only payload I use is relevant to identif
by ubercore 10y ago
So, I've been approaching JWT as a "proof of login" essentially, to handle authentication across web, mobile apps. The only payload I use is relevant to identifying the user logged in. Session data would be handled by server-side code, though it's still early days for me so I haven't had a use for it yet.
After reading this, I'm wondering if I'm misusing JWT, and should replace it for the use-case of authenticating API calls are coming from an identified user in a client agnostic way?
- joepie91_ 10y agoFrom the sounds of it, you're essentially using stateful JWT tokens. In that case, I'd recommend using a battle-tested session implementation for your stack of choice instead, if there is one - this rules out implementation errors or overlooked security issues on your end. Security can get pretty tricky. The exact token scheme you use shouldn't matter for the client. As long as the client supports cookies in some way, it'll just treat it as a dumb blob of text - only the server needs to care about how to interpret the session token.
- ubercore 10y agoI'm using actionhero for the backend. To be clear, I'm not concerned about _sessions_ so much as I'm concerned about authenticating all requests. I guess it's just still not clear to me based on the article and your feedback what the flaw is checking a valid JWT in the Authorization header to identify the user making the request? Other than the relative inability to invalidate sessions (ie, only hacky methods for achieving this)