Security – Is Saving User/Password and Getting Token Automatically Safe?

Consider the first case. Each client gets a random ID that lasts for the duration of the session - which could be several days if you like. Then you store the information relevant to that session somewhere server side. It could be in a file or a database. Let's suppose you pass the ID via a cookie but you could use the URL or an HTTP header.

Session IDs/ Cookies

Pros:

• Easy to code both the client and server.
• Easy to destroy a session when someone logs out.

Cons:

• The server side periodically needs to delete expired sessions where the client didn't logout.
• Every HTTP request requires a lookup to the data store.
• Storage requirements grow as more users have active sessions.
• If there are multiple front end HTTP servers the stored session data needs to be accessible by all of them. This could be a bit more work than storing it on one server. The bigger issues are the data store becomes a single point of failure and it can become a bottleneck.

JSON Web Tokens (JWT)

In the second case the data is stored in a JWT that is passed around instead of on the server.

Pros:

• The server side storage issues are gone.
• The client side code is easy.

Cons:

• The JWT size could be larger than a session ID. It could affect network performance since it is included with each HTTP request.
• The data stored in the JWT is readable by the client. This may be an issue.

• The server side needs code to generate, validate, and read JWTs. It's not hard but there is a bit of a learning curve and security depends on it.

  Anyone who gets a copy of the signing key can create JWTs. You might not know when this happens.

  There was (is?) a bug in some libraries that accepted any JWT signed with the "none" algorithm so anyone could create JWTs that the server would trust.

• In order to revoke a JWT before it expires you need to use a revocation list. This gets you back to the server side storage issues you were trying to avoid.

OAuth

Often OAuth is used for authentication (i.e. identity) but it can be used to share other data like a list of content the user has purchased and is entitled to download. It can also be used to grant access to write to data stored by the third party. You might use OAuth to authenticate users and then use server side storage or JWT for the session data.

Pros:

• No code for users to signup or reset their password.
• No code to send an email with a validation link and then validate the address.
• Users do not need to learn/write-down another username and password.

Cons:

• You depend on the third party in order for your users to use your service. If their service goes down or they discontinue it then you need to figure something else out. Eg: how do you migrate the user's account data if their identity changes from "foo@a.com" to "bar@b.com"?
• Usually you have to write code for each provider. eg Google, Facebook, Twitter.
• You or your users might have privacy concerns. The providers know which of their users use your service.
• You are trusting the provider. It is possible for a provider to issue tokens that are valid for one user to someone else. This could be for lawful purposes or not.

Miscellaneous

• Both session IDs and JWTs can be copied and used by multiple users. You can store the client IP address in a JWT and validate it but that prevents clients from roaming from say Wi-Fi to cellular.

If the token expires during the navigation, jwt-auth library allows you to refresh expired tokens, you should check out the documentation on GitHub.

If necessary, you can still access to user details even if a token has expired, and it gives you the benefits of deciding whether asking the user login again, logging in the user automatically again, or send the an email that gives an option to login directly from it.

If you are afraid that tokens get hijacked, you can blacklist tokens as soon as an user completes the payment, or you can even blacklist expired tokens just to make sure that they are never used again.