Authing Docs

# OIDC FAQ

To understand the common problems contained in OIDC, you can consult this document during development.

# How to deal with OIDC in the backend

Please refer to the example on Github: oidc-demo (opens new window)

# Comparison of the characteristics of the three OIDC certification processes

Features Authorization Code Mode Implicit Mode Mixed Mode
All tokens are returned from authorized endpoints no yes no
All tokens are returned from the token endpoint yes no no
token will not be exposed to the front end yes no no
Client can be authenticated by OP yes no yes
Can refresh token yes no yes
One interaction no yes no
Required server-server communication yes no varies

# Authorization process corresponding to different response-types

"response_type" value Flow
code Authorization Code Flow (authorization code mode)
id_token Implicit Flow (Implicit Mode)
id_token token Implicit Flow (implicit mode)
code id_token Hybrid Flow (hybrid mode)
code token Hybrid Flow (hybrid mode)
code id_token token Hybrid Flow (hybrid mode)

Refer to OIDC specifications (opens new window)

# How to verify the validity of Token

Please refer to:

Verify Token

# User information corresponding to the scope parameter

scope name corresponding information
address address
email email, email_verified
phone phone_number, phone_number_verified
profile birthdate, family_name, gender, given_name, locale, middle_name, name, nickname, picture, preferred_username, profile, updated_at, website, zoneinfo
offline_access If this parameter exists, the token interface will return the refresh_token field

# User information field meaning

Field name Translation
sub Unique ID
name Name
given_name first name
family_name Last Name
middle_name middle name
nickname nickname
preferred_username The name you want to be called
profile Basic information
picture avatar
website Website link
email Email
email_verified Is the email verified
gender gender
birthdate birthday
zoneinfo Time zone
locale area
phone_number phone number
phone_number_verified Verified phone number
address Address
formatted Detailed address
street_address street address
locality city
region Province
postal_code Zip code
country country
updated_at Information update time

Reference OIDC specification (opens new window)

# The difference between IdToken and AccessToken

id_token is equivalent to the user’s ID. The developer’s front-end should carry id_token when accessing the back-end interface. The developer server should verify the user’s id_token, and return relevant resources after verification, which can be used by OIDC The key or OIDC is verified with the public key, and then the user ID and basic information corresponding to this token can be obtained. For sample code, please see: [Use application key to verify Token](../../advanced/verify-jwt-token.md#Use application key to verify-token).

access_token is used to request resources held by the user on the Authing server. Your request to access the Authing server needs to carry this access_token in the Authorization request header. The sample code is as follows:

const axios = require('axios');
axios
  .get({
    url: 'https://core.authing.cn/api/v2/your/resources',
    headers: {
      Authorization: 'Bearer YOUR_OIDC_ACCESS_TOKEN',
    },
  })
  .then((res) => {
    // custom codes
  });

# Why does the OIDC authorization code process require code to token and then user information

Three parties are involved in the authentication process of the OIDC authorization code model: the user, the OIDC server (OP, OIDC Provider), and the application service server (SP, Service Provider).

The interaction purposes of SP, user, and OP are divided into the following points:

  1. The SP wants to get a trusted identity assertion so that the user can log in.
  2. When the SP initiates a login, it will jump to the OP's authentication page. The OP asks the user to log in and authorize his information, and then the OP sends an authorization code code to the SP. In fact, this is passing user information by reference.
  3. After SP receives the authorization code code, it combines Client ID and Client Secret to OP in exchange for the user's access_token.
  4. SP uses access_token to OP to obtain user related information, thereby obtaining a credible identity assertion and allowing the user to log in.

In the OIDC protocol, after the user logs in successfully, the OIDC authentication server will call back the user's browser to a callback address and carry an authorization code code. This authorization code code is generally valid for ten minutes and is valid once, and becomes invalid after use. This avoids the risk of exposing access_token or user information on the front end. The validity period of access_token is relatively long, usually 1 to 2 hours. If leaked, it will have a certain impact on users.

After the backend receives this code, it needs to use Client Id + Client Secret + Code to go to the OIDC authentication server in exchange for the user's access_token. In this step, the OIDC Server actually authenticates the OAuth Client, which can ensure that the machine that obtains the access_token from the OIDC authentication server is trustworthy, and not everyone can come to the OIDC authentication server to exchange the code for the token after getting the code.

If the code is obtained by a hacker, it cannot be used without Client Id + Client Secret. Even if it does, it must compete with the real application server, because the code is effective once and becomes invalid after use, which increases the difficulty of the attack. On the contrary, if the access_token or user information is returned directly without passing through the code, it will affect the user once it is leaked.

← Create OAuth Connection →