First a little background on my use of JWT tokens.
Users (via a web frontend) login to my service through a login HTTP endpoint that includes a username and a password in the request body. Two factor authentication will be added in the future, but can be ignored for now.
The API verifies the login information and issues a JWT token in the response. This token is signed with a symmetric key and includes a userId (UUID) that uniquely identifies the user.
In subsequent API calls, the user includes that token in the Authorization HTTP header as a bearer token. The API verfies the signature of the token and then uses the userId to make sure that the user is authorized by checking the roles of the user (stored in a database).
The token can expire, forcing the user to login again, or they can use a refresh endpoint that verifies the token and issues a new one to bypass logging in each time the token would expire.
What are the best practices for JWT authentication/authorization? Are there flaws with my approach? Is there a risk of using symmetric keys here? I am open to suggestions on better approaches as well.
Related
While I understand how jwt works for authentication, I'm trying to build registration.
Registration has a step that requires verification.
User enters the phone number
Code is sent via sms to user
User enters the code and device is verified
Since it's an API for mobile app there is no session/cookie built in.
I'm wondering if I can not implement cookie like system for mobile. And just make it work with JWT. But I don't have much experience with this.
This is my current flow:
User makes a POST request with Phone #
I respond with JWT (Time:Number)
I also send code via SMS
User sends the code via POST and JWT
Problem:
I don't know if code belongs to user or not, as I didn't save the code in DB.
I can't put into payload as it's just encoded not encrypted. (why is it not encrypted, what's the point of sending plain payload, what's even the point of JWT & didn't signed cookies already do that? they had session string encrypted so you couldn't change session string without invalidating the cookie)
JWT is overcome authentication/authorization mostly in APIs. JWT Access Token/Refresh Token is nothing but a JSON data in an encrypted form. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. Key pair using RSA or ECDSA is more preferable as a security point of view. You can check authentication/authorization by decryption JWTs.
JWT token itself contains expiry date, so you can just configure expiration time to it. Access tokens are to check that user is authorized or not. Refresh tokens is necessary to get a new access token, generally used when the old access tokens are expired. Refresh token and Access token both expire but refresh token is long-lived compare to access tokens.
Generally developers use access token only but it is preferable to use access and refresh token both.
This is not a coding question, but a conceptual question for the correct handling and processing of a refresh token.
I have a single page app which issues a jwt token when logging in. The token works just fine. Now, I want to set the expiration to a low value, and use a refresh token to refresh the bearer token.
The question is, what claims should be stored in the refresh token? And what steps are supposed to be done to validate the refresh token before issuing a new token?
For example, right now my refresh token is a jwt which stores an expiration, so the client knows when the refresh token expires, and a username claim so that I know what user the refresh token is associated with.
So then when the refresh token is recieved:
Check that it is not expired.
Check that it has not been revoked.
Use the UserName in the refresh token to issue a new short-lived bearer token.
Is this the correct workflow for this? I just want to make sure I am not missing any security checks.
If your application is a single page application, you should not use long lived refresh tokens as you have no way of securely storing them.
OAuth2 defines a number of grant flows for different types of clients (which I've described here). Refresh tokens are only meant for confidential clients (like web applications living on a secured server).
Your refresh token is just as vulnerable to theft as your access token, since both are bearer tokens stored on the client.
Some OAuth libraries allow SPA or other non-confidential clients to get a new access token by talking to the token endpoint of the authorization server using a session token in a cookie. As long as the cookie is valid, the user can get a new access token. After that, the user will need to re-authenticate. Of course cookies can be marked secure and http only, making them harder to steal.
If you issue the JWT tokens from the same service endpoint that consumes the access tokens, you could have the client include a nonce in the token request that you hash and include as a claim in the token. The client can send the JWT in the Authorization header and the nonce in a custom header. Your token verification would hash the nonce again and compare it to the claim in the JWT. That way, if your token is stolen is harder to use without the nonce value. Of course, in a targeted attack, your nonce could also be stolen.
I've been trying to understand the real differences between session and token authentication.
What I have gathered so far:
In token authentication, nothing is stored in the server side. What this means is, that the actual token includes the password and username, as well as other possible information. And the server just decrypts the token, and then checks whether the username and password are correct. Am I right about this?? If the token includes the password and username, then how can the token still be different everytime?
In session-based authentication, the session token is just a random (unique in time) id, that is mapped to the user in the server side. So that when the server receives the session_id (in cookie for example), it will check whether it maps to any user, and if it does, then the user is authenticated. So the session_id does not contain any user related information, that could be decrypted?
In session authentication, the server will send back the user related information (not password) without encryption (unless https is used).
In token authentication, the server will not send back direct user information, but just the token, which contains the user information, once decrypted?
I have a feeling that I haven't really understood how token and session authentication works. Something is definitely wrong in the statements above.
But, let's play along that the statements would be correct. Then wouldn't session-based authentication be more secure? Because in session based authentication, you do not reveal user password (in browser for example). Since it's just a random id, one cannot get information from it. But this is not the case with Token authentication. Since token authentication contains the password, if someone manages to decrypt it, he will get your password. So isn't the session authentication actually more safe than the token authentication, as it doesn't reveal password nor username information?
Your question has not an absolute answer YES/NO. For example session cookies are vulnerable to CSRF and tokens can be stolen with XSS injection. Both mechanism are also vulnerable to ManInTheMiddle if you do not use HTTPS. Therefore additional security measures are needed usually for each solutions. Depends on your use case.
I guess you are talking about a token mechanism like JWT which is self-contained and protected to alterations because you said
In token authentication, nothing is stored in the server side.
But you are confusing some concepts. I will try to answer your additional questions using JWT tokens as reference. If not, most concepts also can be applied to opaque tokens
In token authentication, nothing is stored in the server side. What this means is, that the actual token includes the password and username, as well as other possible information. And the server just decrypts the token, and then checks whether the username and password are correct. Am I right about this??
The token is issued by server (not client) requiring users to present their credentials and digitally signed with server private key. The token includes an identifier of the principal in the sub claim and other fields of interest like expiration time or issuer. Never the password
When the client send to token to authenticate, the server verifies the signature to determine the authenticity an has not been altered
If the token includes the password and username, then how can the token still be different everytime?
The token does not include the password. The token will be different due to some variant claims like expiration time exp or issued at iat. Also the computed signature will be different
So the session_id does not contain any user related information, that could be decrypted?
Yes, it is a ramdom sequence. Relationship with user server is stored on server
In token authentication, the server will not send back direct user information, but just the token, which contains the user information, once decrypted?
The JWT token includes some user information, but it is not encrypted, it is signed. If you need to hide the payload, JWT also allows to use JWE encryption
But, let's play along that the statements would be correct. Then wouldn't session-based authentication be more secure? Because in session based authentication, you do not reveal user password (in browser for example). Since it's just a random id, one cannot get information from it. But this is not the case with Token authentication. Since token authentication contains the password, if someone manages to decrypt it, he will get your password. So isn't the session authentication actually more safe than the token authentication, as it doesn't reveal password nor username information?
The base approach is wrong. Password is never included in the token. If you do not want to reveal user data you can use opaque tokens or JWE encryption with JWT. The proper solution depends on your use case. See my first paragraph
Sensitive information such as password or items like Social Security Numbers shouldn't be stored in a token.
A typical example of token signing is this
function createToken(user) {
return jwt.sign(_.omit(user, 'password'), config.secret, { expiresIn: 60*60*5 });
}
Here, we are creating a signed token with the user's details but we are leaving out the password.
I gave a very detailed information about this in this thread How is JSON Web Token more secure than cookie/session?
Check it out. I hope this information helps!
I know there are already many posts about Oauth, Oauth2, JWT, etc.. I have read many and I more confused than ever so I am looking for some clarification. I will propose my view on the subject and I hope somebody can tell me if my implementation is secure enough or what I am doing wrong and how to improve it.
I am building an API Rest server for serving my resources to my users. Let's suppose it is a bank app where users can deposit, withdraw and transfer money.
I am using nodejs, hapijs, jsonwebtokens, and bcrypt for my server. I want to implement two token authentication flow (Oauth2).
This is the way I am doing it:
User logs in to the auth server by giving some credentials (username and password).
The server verifies the user's credentials, if they are valid, it will grant access to the user and return a refresh token and an access token.
These tokens are saved into the local storage of the browser or mobile device.
The access token:
is signed as a jsonwebtoken.
contains issued date, expiration date (5 min), user data (id, username).
The refresh token:
is signed as a jsonwebtoken and encrypted with bcrypt.
contains a unique identifier
may contain an expiration date
is saved in the database.
As long as the access token is valid, that means, it has not expired and contains valid user data, the resource server serves the user the requested resources.
When the access token is no longer valid, the auth server requests the client to provide a refresh token in order to issue a new access token
The server receives the refresh token from the user, decrypts it, compares it to the one in the database, checks if it has been revoked, and checks its unique identifier.
If the refresh token passes all tests, the server issues a new access token to the client.
If the refresh token fails one test, the server requests the user to re-authenticate.
Notes: I am trying to avoid the usage of cookies.
Questions:
If the user is able to steal an access token, I guess it can also steal the refresh token. So, how can I make the refresh token more secure?
Is my perspective of the Oauth2 flow correct?
What can I improve?
Am I missing something?
The reason OAuth2 is so confusion to many people is because it uses different authentication flows depending on what kind of client is used.
OAuth2 distinguishes two client type, confidential or public. Next to that, there are 2 grant flows that are redirection based (auth code and implicit) which are meant to be used with a browser or browser control.
The other two flows (resource owner password and client credentials) are meant to be used from non-browser apps (CLI, background services, trusted mobile clients).
I've described the different flows and when to use them in more detail in this answer here.
I authorize all REST API requests by checking token in Authorization header:
POST /rest/resource HTTP/1.1
Host: domain.com
Authorization: Bearer AbCdEf123456
The token is plain text, using HTTPS. However, the token is salted and hashed in the database.
How could I authenticate the request?
send also user id to the server, select token hash for this user from the database, check if the token is correct (issue with sending user id - where to put it)
check if some hash in the database corresponds to the token received from the user (performance issue)
There must be some elegant way since for example for google maps the "API key" (token) is sufficient.
Use JWT (JSON Web Token) as authorization bearer. JWT can have user id in the payload. You can also easily verify if JWT was issued by trusted party (probably you).
The good thing is that you can verify JWT without reading values form database. It is completely stateless.
This is simple explanation how JWT works:
http://www.intridea.com/blog/2013/11/7/json-web-token-the-useful-little-standard-you-haven-t-heard-about
You can find library for JWT for almost any language (just google it)