About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
Thanks for the great article! One remark: I would not put the actual twitter token inside the JWT. If the interaction is over plain HTTP, the token can be easily intercepted. I would suggest adding the Secure flag to the cookie. tools.ietf.org/html/rfc6265#sectio... The best would be to store only the user/session id in the JWT because it is unpredictable where the data leaks eventually.
Also, in my opinion, the expiration for JWTs is a must. Otherwise, the token gives a forever access to the service. I would highlight that.
I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Excellent point, Alex! I'll update my lecture and code on this as it clearly would be a potential leak. What do you think about using a constantly changing identifier on the session as I mentioned in the reply above?
About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
I think that would work for the session/client-auth use case. I mostly use JWTs in a distributed system where a token is an authorization to access a specific service (also backend-to-backend). For this use case, I always need the user ID in the token. Constantly changing identifier would be problematic to use because the service does not have access to the session or user data usually.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the great article! One remark: I would not put the actual twitter token inside the JWT. If the interaction is over plain HTTP, the token can be easily intercepted. I would suggest adding the Secure flag to the cookie. tools.ietf.org/html/rfc6265#sectio... The best would be to store only the user/session id in the JWT because it is unpredictable where the data leaks eventually.
Also, in my opinion, the expiration for JWTs is a must. Otherwise, the token gives a forever access to the service. I would highlight that.
Excellent point, Alex! I'll update my lecture and code on this as it clearly would be a potential leak. What do you think about using a constantly changing identifier on the session as I mentioned in the reply above?
I think that would work for the session/client-auth use case. I mostly use JWTs in a distributed system where a token is an authorization to access a specific service (also backend-to-backend). For this use case, I always need the user ID in the token. Constantly changing identifier would be problematic to use because the service does not have access to the session or user data usually.