The key to using OAuth 2.0 authentication on the front-end is to understand the authorization process and correctly implement request and callback processing. 1. Initiate an authorization request: Construct a third-party authorization URL, including scope, client_id, redirect_uri, response_type and other parameters, and guide the user to jump or pop-up login; 2. Process callback: Extract the code from the URL parameters of redirect_uri and send it to the backend to exchange for the token; 3. Store and use token: Safely store the token into localStorage or memory, and carry it in the Authorization header of each API request; 4. Associate the local account: the backend binds the OAuth user to the local account through provider and provider_id to achieve multi-way login unified. The entire process requires security, such as preventing XSS and avoiding storing tokens into cookies.

The front-end authentication using OAuth 2.0 is not as mysterious as it sounds. In essence, it is to let third-party services (such as Google and GitHub) help you verify the user identity, and then return a token, and the front-end uses this token to access its own back-end interface.

The key to the entire process is to understand the authorization process of OAuth and to correctly initiate requests and handle callbacks on the front end. Let’s talk about how to achieve this from a few practical perspectives.

How to initiate an OAuth authorization request

The first step is to guide the user to jump to the third-party authorization page. This step is usually by splicing a URL, allowing the user to click or jump automatically.

Taking Google Login as an example, you need to construct a link like this:

 https://accounts.google.com/o/oauth2/v2/auth?
  scope=email profile&
  client_id=your client_id&
  redirect_uri=your callback address&
  response_type=code&
  state=Random string

• scope is the permission range you want to obtain, such as email and profile.
• client_id is the application ID you applied for on a third-party platform.
• redirect_uri is the address that jumps back to your front-end application after the user authorization.
• response_type=code means that what you want to obtain is an Authorization Code.

The usual practice is to provide a "login button" on the front end and click it and jump to this link. Some websites will open the authorization page in pop-up windows, which can prevent the main page from refreshing.

How to handle OAuth callbacks

After the user authorization is completed, the third party will redirect the user to redirect_uri you set and will come with a code parameter. At this time, your front-end needs to send this code to the back-end for the next step to exchange for the token.

For example: the user is redirected to https://your-site.com/auth/callback?code=abc123xyz . You can extract the code in JS on this page, and then send a POST request to a backend interface like /auth/google .

 const urlParams = new URLSearchParams(window.location.search);
const code = urlParams.get('code');

fetch('/auth/google', {
  method: 'POST',
  body: JSON.stringify({ code }),
  headers: { 'Content-Type': 'application/json' }
})
.then(res => res.json())
.then(data => {
  // Store token to localStorage or localStorage.setItem('token', data.token);
});

Notice:

• Do not store tokens to cookies directly at this stage, as it may easily cause security issues.
• If you are a single page application (SPA), remember to handle it separately for /auth/callback in the routing configuration.

How to use Token? Where does it exist?

After you get the token, you have the credentials to access your backend API. It is generally done to bring it with you every time you request it and put it in the Authorization field of the HTTP header:

 fetch('/api/user/me', {
  headers: {
    Authorization: `Bearer ${localStorage.getItem('token')}`
  }
});

There are several options for the storage location of a token:

• localStorage : Suitable for long-term effective tokens, but pay attention to XSS risks.
• Memory variables : safer, but refresh the page will be lost.
• Secure cookie HttpOnly : It is more suitable for backend control, and the frontend does not recommend direct operation.

If your token has an expiration time, it is recommended to record the expiration time on the front end and automatically refresh before it is about to expire (provided that the backend supports refresh tokens).

How to associate third-party login with local accounts

Many products allow users to log in through OAuth or use local accounts. At this time, you need to consider how to map OAuth users to users in the local database.

Common practices are:

1. When the user logs in through OAuth for the first time, the backend checks whether there is a binding record.
2. If not, create a new local account and associate it with the OAuth ID.
3. When logging in later, find the corresponding local user based on the OAuth ID.

You can maintain a table for each OAuth user, such as user_oauth_providers , which records fields such as provider (such as google, github), provider_id (the unique identifier of third-party users), user_id (the ID of local users).

The advantage of this is that it can support multiple OAuth platforms to log in to the same account, and it can also allow users to bind or unbind later.

Basically that's it. OAuth itself is a protocol specification, and the front-end only needs to follow the process. The key is not to miss key steps, such as handling callbacks, safely storing tokens, and cooperating with the backend.

The above is the detailed content of Implementing Frontend Authentication with OAuth 2.0. For more information, please follow other related articles on the PHP Chinese website!