I can't imagine anything in the tech world that would sound so similar and frustrates when you are trying to find the difference but Authentication and Authorization. As Front End developers we are facing these terms quite often, mostly to build system using it.

But how exactly we can develop such a thing? What is the real difference? Let's start by defining how these terms differ from each other to understand how we could implement it in our app.

By the end of this post, you will know how to use authentication in your project using React.

 is where your meaningful application usually starts and ends. It answers the question 

 For all kinds of applications, you'll most likely need that feature for various reasons. These things we are facing daily - Login/Password, 2FA, Certificates, Biometric like FaceID, TouchID, Physical tokens, OpenID - those are all approaches of Authentication.

 is the next step which answers a bit different question - 

 - Role-Based Access Control. As for extra examples of access control systems that can be used - 

. Though RBAC is defined as the go-to solution for most of the cases.

It's not that important what kind of application you are building. Usual user interaction with your app will go as follows:

Let's start with how we define Authentication. Interface for authentication is consist of 2 basics:

Any approach to authentication gives you a way to generate an identifier that could be used in the system to process further requests. Any key that you have configured for authentication - login and password, 2FA time-based code, face or fingerprint used to generate the identifier. 

A service on your back end to recognize already logged in users. This function is in control of all user app activity. It handles how we are saving identifiers within our app, how long we are allowing users to use an app without religion.

When building an authentication system the most challenging part is on the back end. You need to provide scalable service to work as a source of truth for all of your users. Building your own solution with default criteria like "I want to let users in by their email and password" or "I want also to let them in with 2FA for security reasons" most likely would just add extra service to increase your technical debt. Discuss with your team what would be more suitable for your product.

Sometimes you don't need to build it on your own as you can use something from existing services. 

There are good production-ready providers that could save your time:

They usually come with different identification strategies already built-in. You can have social integration in 2 clicks. Some of them would also provide front end components that you can use or extend.

Now we have Back End for our authentication following the process described above, it returns our identified user. We are ready to proceed with cool looking front end built with the currently popular framework.

To do that with examples, we are going to use React + 

 on Front End and Express on Back End. If you are not really familiar with typed JS or observables, I would really recommend to check out these articles:

React is the most popular library to build your front end at the moment. But there is no specific answer in the article as to why you should use exactly React, all approaches we are going to look at could be used with Vue, Angular or vanilla JS.

We will use latest feature from React like hooks. If you haven't used them by now check 

We are just about to build our web app and let all of our components to know about the user. Our front end work here is to:

All of code examples could be found in the 

Our web app may have more dynamic requests for data or view but what we want to do here is put our request in parallel, so our user will be defined as soon as possible. To do that we have 2 ways when to trigger user load:

As we most likely will have 1 user authenticated and based on that info we would proceed with further app logic, the first scenario is better for us. That's why we putting it in the place where we render the component.

Let's start with defining function where we sending the request to our API to get the user.

import axios, { AxiosRequestConfig } from 'axios';

// Token might be defined in cookie/localStorage/wherever on FE side so we could identify
// user for multiple logins
const defaultUserId = '1';

export type userDetail = {
  id: number;
  first_name: string;
};

export type userAd = {
  company: string;
}

export type userModel = {
  data: userDetail;
  ad: userAd;
};

export function loadUserByToken(userId = defaultUserId, requestConfig?: AxiosRequestConfig): Promise<userModel> {
    return axios(`https://reqres.in/api/users/${userId}`, requestConfig).then(({data: user}) => user);
}

 as a library to fetch data, but pretty the same could be done with regular fetch request with defining a bit more info.

As a mock for our user info, we are using service 

. It just returns user info on specific IDs.

 for demo purposes but in a real app, you will not have an id before you render. You will have your identifier stored in cookies, localStorage, sessionStorage on the user side. We need that to let our system know on user return and not ask a user to log in each time they visit our app. In the end, this identification will serve the same idea - ask API for authentication by identifier.

export async function logUserIn(userId: string) {
  loadUserByToken(userId) // get user
    .then(saveUserInStore) // save user
    .then(() => logUserInLocalSystem(userId)) // check user with own API
    .then(() => checkForUserLogout(userId, setUndefinedUser)) // check if user Logged out on different page
    .catch(setUndefinedUser) // clear user if error happen
}

Here is how we triggering this static request right before rendering app:

logUserIn('1');

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

To serve the global state that should be accessible outside of component we cannot use only context and hooks so we will define a MobX store to follow our authentication process.  But on another hand, we can have a case with the need to serve data only in component, for that we will use local state with hooks.

Let's do examples on how saving could be done using both approaches.

Define your User store, what data would you use in your app. Observables let us create simple objects without the need to create all actions around them, this approach is quite straightforward and best for demo purposes.

import { observable, computed } from 'mobx';
import { userModel, loadUserByToken, checkForUserLogout, releaseUserLogout } from './loadUserByToken';
import { logUserInLocalSystem, logUserOutLocalSystem } from './logUserInLocalSystem';

type user = { id: number | null, name: string | null, isLoaded: boolean, company: string | null };

export const userStore = observable({
  id: null,
  name: null,
  isLoaded: false,
  company: null,
} as user);

export const isLoggedIn = computed<boolean>(() => userStore.id !== null && userStore.isLoaded === true);

export function saveUserInStore(userToStore: userModel) {
  userStore.id = userToStore.data.id;
  userStore.name = userToStore.data.first_name;
  userStore.company = userToStore.ad.company;
  userStore.isLoaded = true;
}

export function setUndefinedUser() {
  if (userStore.id) {
    logUserOutLocalSystem(userStore.id)
    releaseUserLogout()
  }
  userStore.id = null;
  userStore.name = null;
  userStore.company = null;
  userStore.isLoaded = true;
}


After defining your store you need just to use it inside a component where you expect reading user data. To do that you need to get the user from this store, with injecting or importing directly - depends on your architecture.

import React from 'react'
import { observer } from 'mobx-react';
import { user } from './userStore';

export const ExampleUserStore = observer(() => {
  return (
    <div>
      {user.id} {user.name}
    </div>
  )
});

As an alternative approach to direct import, you could think about putting a wrapper around this store like 

 and inject your global user wherever you need it. 

import axios from 'axios';
import { useEffect, useState } from 'react';
import { loadUserByToken, userModel } from './loadUserByToken';

const CancelToken = axios.CancelToken;

export function useUser(userId: string = '1') {
  const [user, setUser] = useState<userModel | null>(null);
  useEffect(() => {
    const requestSource = CancelToken.source();
    if (!user) {
      loadUserByToken(userId, {cancelToken: requestSource.token})
        .then((user: userModel) => {
          setUser(user);
        });
    }
    return () => requestSource.cancel('Component disposed');
  }, [user, setUser, userId]);
  return [user, setUser] as const;
}

Once we are about to render a component with the hook 

 it will create a local state with a user loaded if not found. As we may use this hook multiple times in different components we need to make sure we are not requesting redundant data when component not rendering anymore. That's why we defined cancel callback on 

Then in our actual component, we just using this as regular hook.

import React from 'react'
import { useUser } from './useUser'

type Props = {
  id: string;
}

export function ExampleUseUser({ id }: Props) {
  const [user] = useUser(id);
  if (!user) return <div>no user</div>;
  return (
    <div>
      {user.id} {user.first_name}
    </div>
  )
}

If the user is not defined and we cannot proceed with the positive flow - we need to provide a fallback to our login page. It could be just a history replacement or usage of a provider like react-router.

Within our simple page let's say instead of going to the different page we just want to replace our UI to show the input to say what user we are.

import React, { useState } from 'react'
import { observer } from 'mobx-react'
import { logUserIn, isLoggedIn } from './userStore';

type Props = {
  children: JSX.Element[] | JSX.Element;
};

export const Login = observer(({ children }: Props) => {
  const [login, setLogin] = useState<string>('');
  const [password, setPassword] = useState<string>('');
  if (isLoggedIn) {
    return (
      <form onSubmit={(event) => {
        event.preventDefault();
        logUserIn(login);
      }}>
        <input type="text" placeholder="login" value={login} onChange={(event) => setLogin(event.target.value)} />
        <br/>
        <input type="password" placeholder="password" value={password} onChange={(event) => setPassword(event.target.value)} />
        <br/>
        <button type="submit">log in</button>
      </form>
    )
  }
  return <>{children}</>;
})



This small component lets us define a wrapper around other components that rely on 

 is wrong we will get fallback to this component with canceling other requests if they are still in progress.

And this is how we are wrapping components that rely on data. Here we are assuming that all of the UI relies on the user to be logged in, and once we are putting correct keys - the full data will come up.

At some point your users may want to log out from your service, so don't forget to let them. A simple function that removes you from the service would work just fine.

 all we need to let some button trigger it.

Let's have this button right under user details.

Login and signup forms are usually the first screens your users faced if the user is not found. You may have them manually crafted or generated by some package like 

. The logic for these screens would be as follows:

As you can see these forms are sharing some logic with our Authentication. Full implementation for them would deserve a separate post so we wouldn't describe them fully here.

When building a public application you may have a lot of functionality shared between random users accessing your app or logged in user who is looking for the same page. Let's build an example of a component that has a difference.

This component would have a condition on what to show depending on the state. You could split them into different pure components or keep in the one, absolutely up to your decision but overall it would be similar to the next component:

src/user/ExampleExtraInfoWhenLoggedIn.tsx

import React from 'react'
import { isLoggedIn } from './userStore'
import { observer } from 'mobx-react';
import { useUser } from './useUser';

export const ExampleExtraInfoWhenLoggedIn = observer(() => {
  const [user] = useUser('5');
  if (!user?.data.id) return null;
  const text = `${user?.data?.first_name} ${isLoggedIn ? `is working at ${user?.ad.company}` : ''}`;
  return (
    <div>
      {text}
    </div>
  )
});



This component would render only the first name if we are logged in. After login, we will see where this person is working.

There are no specific cases to have extra security problems with React. All of the restrictions touching WEB and browser connection to a server as - "You should prefer secure protocol" and "Don't include viable secrets within your FE code".

 is pretty a standard over the internet it shouldn't be too hard to migrate your current API to secure version. Secrets on another hand still could be found in dark edges of your FE app.

Some authentication could be implemented with thinking - It is harmful to pass bare passwords to back end and validate there. This approach leads to implementing encryption on FE and opens your app to

 over https, it will do all the work for you.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

React Authentication why & how

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript