Discussion on "React & JWT Authentication - the right way!"

Gal Malachi · 2020-09-29T13:10:09.465Z

In this series of posts, we create a secured end-to-end JWT-based authentication mechanism using NodeJS, Express, PassportJS, and React. In this series I cover: Part 1: Background and Backend using NodeJS Part 2: React & JWT Authentication (This p...

Thanks, Gal. 4 years already and still great content. I'm a new to React and probably missing some basic knowledge, but what is the AuthEvents in your code?

Assuming that the user has logged previously and that we have a valid refresh-token stored in a cookie, when we start the application again, user will be null until the token is refreshed.

Since user is null, any protected route will be redirected to login.

How do you usually wait for the first refresh to complete so the user is not redirected to login?

I figured it out. I've added a state 'waitingForToken' that is initially true.

    const [user, setUser] = useState(null);
    const [waitingForToken, setWaitingForToken] = useState(true);
    const refreshToken = useCallback(refresh, []);

In refresh(), I set the state to false.

    async function refresh() {
        try {
            const {
                data: { user, ...rest },
            } = await axios.post('refresh-token', {}, { withCredentials: true });
            setUser(user);
            setToken(rest);
        }
        finally {
            setWaitingForToken(false);
        }
    }

And export it:

    return {
        user,
        waitingForToken,
        setUser,

Then in my App:

const App = () => {
    const { waitingForToken } = AuthContainer.useContainer();
    return (waitingForToken ? <div/> :
        <Switch>
            <Route path="/login" component={Login} />
            <ProtectedRoute exact={true} path="/" component={Dashboard} />
            <ProtectedRoute path="/settings" component={Settings} />
            <ProtectedRoute component={Dashboard} />
        </Switch>                
    );

Hope this can help someone!

Great addition, thanks Martin Filteau, Eng., PMP 💪🏽

What happens when the token should be refreshed and you have multiple requests that are being sent at that time? Won't all the request get 401?

Yes, you are right. To prevent that we should send the refresh-token request few seconds before it expires. I will add that in.

Gal Malachi I usually have a retry logic. So if it happens and a request is sent and has a 401 it will get the token and add it to retry list using the promise. If requests are being sent after sending the request to get the token but before setting it, I add it to the retry list. So using the request(the ones that should be sent) and response(the ones that got 401) interceptors I will add the request to the retry list and send them when the token has been refreshed using the promises(replace the old token). I use a timer to refresh the tokens but also have the retry logic attached to that. The oauth2 implementation I have worked with will not provide new tokens unless the old ones are expired, even if it would I think there are scenarios where the token would be invalid for current request. But even with this implementation I am unsure if this is a good solution, I feel there could be other scenarios in which the token would not be used/refreshed properly.

rasd sounds like a complete solution! I thought about setting a retry logic, but I didn’t want to complicate stuff since this post is very long as is. However, I do believe that calling the refresh endpoint few seconds before the token expires should cover 99% of the cases.

Thanks Gal for this interesting post. Much appreciated

Thanks for the feedback, Hod! Glad you found it interesting!

Discussion

React & JWT Authentication - the right way!

Responses(4)

Recent in Forum

Search Hashnode

React & JWT Authentication - the right way!

Responses(4)

Recent in Forum