I am fairly new to implementing JWT. I had a few questions while implementing JWT. I am using axios to make requests.
When the user logs in or registers. I get an accessToken, which expires in a few days. I dont have a refreshToken because I think the backend is built on django rest framework.
Now if I get a status code of 401 in a request, I try to check if the token has expired and if yes, then refresh the accessToken, but at times even the refresh token api returns 400 suggesting that this token is also expired, at which point I need the user to log out.
I think this is a bad User Experience, Why is that we cannot refresh the token using old token. Is there a way to keep it from expiring? Can anyone point me to an example which solves the following problem with a correct implementation of axios interceptors?
Since you are using Django rest framework, consider using Djoser with JWT tokens, then djoser sends you access and refresh tokens from the backend. Once the backend preparation is over, follow this simple article to refresh and access tokens automatically from react native. Hope it helps you.
You can create a token which will never expire but that's a bad idea for security reasons. If the token is stolen then someone can always access the user's data. You can set the expiration date in exp claim. Read more here: https://gist.github.com/soulmachine/b368ce7292ddd7f91c15accccc02b8df
Related
Microsoft started to turn of basic authorization for Exchange Online and we must move to modern one.
We chose auhtorization code flow. User process authorization, we get auth code in url send it to server and get access/refresh token. Unfortunately default refresh token lifetime for SPA is 24 hours. Thats problem because we want to use refresh token later (e.g. days, months) in webjobs/api.
Our scenario:
User process authorization, scope is mail.send offline_access
We get auth code and send it to server
Server use auth code to get tokens
Tokens are valid and saved to database
Several days ago we use refresh token to gen new access token but request ends with exception (24 hour lifetime exceeded)
Our requirements in nutshell: Users allow us to send mail. Server save tokens and use them later in webjobs, api etc.
Can someone give us advice what is the proper way to get refresh token for long term use?
I have built an application with the MERN stack (Mongo, Express, React & NodeJs). Now I am doing research on building an authentication system. There are literally tons and tons of tutorials and video's where a system is built on which the user is authenticated for a maximum of let's say 24 hours and then has to re-login. They all use either jwt or session with something like express-session. However, I am using certain websites where I am basically never logged out.
I would really like to create a system myself where the user is authenticated for atleast 14 to 30 days without being prompted to re-login (ideally even longer). I cannot find good resources online on how to persist user login for long periods of time. I am aware that there are massive security trade-offs involved in creating such a system. I am also aware that I can just set the expiry time of a jwt or the maxAge of a session cookie to something like 14-30 days, but that seems like a really bad idea. However, I would really like to learn & read more about these authentication methods with persistent login over long periods of time.
Could someone provide some good resources / insights on this particular subject? What are some things that I should take into account?
Generally, because security is difficult to implement correctly, it's recommended to use a third-party OAuth provider or at least a well-tested library for local authentication and authorization.
If you want to build your own system, you can implement a system with two tokens. An authorization token and a refresh token. Set the expiry on the auth token to something short like an hour and the refresh token for as long as you'd like.
Pass the auth token on all requests and validate it on the back end. When the auth token expires, the server sends back an invalid token message and the client should then request a new auth token passing the refresh token. The server validates the refresh token and issues a new auth and refresh token to the client. This process repeats until the refresh token expires.
If both tokens expire, then the user must re-authenticate. When a user logs out, you need to expire / delete the auth and refresh tokens on both the client and server.
This system minimizes the exposure of a captured auth token while enabling the client access over longer periods of time.
This is only a rough, and simplified version of how such a system could work. You'll have to come up with some way to validate tokens and keep track of which tokens belong to which users.
For long period time sessions using stateless jwt may not be best idea.
As critical requirement would be session invalidations, token theft detection, which jwt by itself cannot provide. You need some surrounding smart components for the whole setup.
Stateless JWT tokens cannot be invalidated or updated, and will introduce either size issues or security issues depending on where you store them. Stateful JWT tokens are functionally the same as session cookies, but without the battle-tested and well-reviewed implementations or client support.
Unless you work on a Reddit-scale application, there's no reason to be using JWT tokens as a session mechanism. Just use sessions.
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
I'm new to webdev and have implemented access token & refresh token based authentication in my express project. However, the more I look over the implementation I'm starting to question why access tokens exist when it appears that refresh tokens make them redundant. Perhaps it's just my implementation.
For any task that needs authentication, I send off a cookie with both an access token and refresh token to an auth server. It looks at the access token, and if it is both valid and unexpired, it will send a 200 back and allow any express middleware to continue on.
However if it has expired, it will then query a database to see if a matching refresh token exists and, if so, will send a new access token.
As the lifetime of the access token decreases, the auth server will need to do more database searches to verify the refresh token. At that rate, why bother with the access token and instead why not rely solely on the refresh token? After all, the refresh token can be removed from the database and the authorisation server can reject any requests made with it.
The only reason I can think of the access tokens existing is to reduce how often a page will need to query a database, but that seems too simple. Since I'm fairly new to this, I know I must be missing some larger concept. Can anyone enlighten me?
While building my website I decided to use JWT for the authentication feature. In the front-end I have React and in back-end Express server with Postgres database.
Right now when user tries to log in, I verify his credentials against the database and then issue a token, which then is stored in http-only cookie in the browser.
However right now I'm struggling with some front-end problems. I need to have some sort of 'CurrentUser' object on the client side. The problem is that I can't decode token and retrieve data from it using React, since it is http-only. I could additionally send user credentials along with the token and then store them in local/session storage, but that doesn't seem secure to me.
Perhaps I misunderstand something about the applications of JWT, if so, could you please correct me and give some advice about how I should handle my authentication ?
I'm currently using firebase.auth().createUserWithEmailAndPassword(email, password) to authenticate users and using the JWT token from firebase.auth().currentUser.getToken(true) for API requests. However, Firebase is invalidating the token after 1 hour. So I'm wondering how should I refresh the token. Do I have to use my own custom token generation to properly utilize token refreshing?
I'm currently using this though I only tested it once but it seems to work.
firebase.auth().onAuthStateChanged(function () { // Refresh token here })
I've been reading the docs over and over again and haven't seen any mentions of refreshing the tokens for the Web Apps. I've also looked at example repositories for firebase and have not seen anyone use onAuthStateChanged for something like this. So I'm wondering is this the right approach for client side token refresh? The reason why I feel this might not be the best approach is because this might have a race condition. For example if the token expires and I send an API request with the old token before I refresh the token then my API request will have an auth failure for token expiration.
This is very similar to the question in Firebase DB HTTP API Auth: When and how to refresh JWT token? but slightly different in the sense that the question is for using Python and no mentions of onAuthStateChanged.
Thanks!
For those who came into this post looking for an answer. You can grab the token right before all your API calls to get the token.
// Make sure you don't pass in true which will always refresh the token
firebase.auth().currentUser.getToken()
Firebase will internally determine if the token needs to be refreshed or grab from cache. If you notice Firebase will not send any network requests until the token is expired.