Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
2 added 12 characters in body; edited tags; edited title
source | link

is Is storing a user id in JWT enough to verify the identity?

I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like thatthis:

{ id: "1234abcd", iat: 1522779638 }

{
  id: "1234abcd",
  iat: 1522779638
}

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?

is storing a user id in JWT enough to verify the identity?

I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like that:

{ id: "1234abcd", iat: 1522779638 }

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?

Is storing a user id in JWT enough to verify the identity?

I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like this:

{
  id: "1234abcd",
  iat: 1522779638
}

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?

1
source | link

is storing a user id in JWT enough to verify the identity?

I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like that:

{ id: "1234abcd", iat: 1522779638 }

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?