# Use OIDC authorization
Combine Authing to realize OIDC authorization method.
# Terms
End-User: end-user, can also be understood as the person who uses your softwareRP (Relying-Party): server backendOP (OIDC Provider): Authing server
The two domain names testapp.authing.cn and example.authing.cn appearing in the P.S. document are second-level domain names that can be configured on the console.
# Create a user pool in Authing
To use OIDC, you need to register an Authing account (opens new window) and [create a new user pool](/quickstart/create-authing-account.md#create your first user pool).
# Create an application
After registering an Authing account and creating a user pool, you need to create an application, and then you can use the OIDC protocol to complete user login and information authorization. For creating applications, please refer to:
Create OIDC application# The basic flow of OIDC authorization login
- The user accesses the authorization link to log in;
- After successful login, call back to the redirect_uri configured by the developer and attach relevant parameters to the URL query;
- If the return type is code, then the developer needs to use code and secret on the backend (you will get it after creating the OIDC application) in exchange for access_token;
- If the return type is id_token token, then id_token and access_token will be directly attached to the callback URI after the user logs in successfully;
- Use access_token in the backend to exchange user information (userInfo) to complete identity authentication;
If you want to experience the OIDC certification process intuitively, please click here to view the examples we provide (opens new window) or [click here to understand OIDC visually](https://openidconnect .net/).
If you are confused about how to handle OIDC on the backend, please refer to the sample code on Github: oidc-demo (opens new window).
# Use authorization code mode (Authorization Code Flow)
The authorization code mode is the most commonly used mode in OIDC authorized login. The OP server returns an authorization code code to the developer's back-end server. The back-end completes the code in exchange for access_token, and then uses access_token to exchange for user information, thereby realizing user identity authentication .
# 01-Configure OIDC application in the console
Go to Control Panel> Applications> Application List, find your application, click "Configuration", in the application configuration tab, find the authorization mode, open the authorization_code mode, and click below Select the return type of code at the return type.
Configure OIDC application
# 02-Initiate a login request
Splice a link and allow the end user to access it in the browser to initiate an OIDC authorization login request.
To initiate authorization, you need to splice a URL for authorization and allow end users to access it in a browser. The specific parameters are as follows:
Example request:
https://yourdomain.authing.cn/oidc/auth?client_id=5c9b079883e333d55a101082&redirect_uri=https://www.example.cn/example&scope=openid profile&response_type=code&state=52378542395
If you need to refresh the access_token later, please stitch the login link in the following way
Example of login request with refresh token function:
https://yourdomain.authing.cn/oidc/auth?client_id=5c9b079883e333d55a101082&redirect_uri=https://example.com&scope=openid profile offline_access&response_type=code&prompt=consent&state=235345
Reference materials:
- [Scope and user information correspondence table] (oidc-params.md#scope-parameter corresponding user information)
- response_type parameter OIDC specification (opens new window)
- prompt parameter OIDC specification (opens new window)
# 03-User Login
After initiating OIDC login, if the user has not logged in at OP before, OP will redirect the user to the login page and guide the user to complete the authentication at OP. At this time, the user needs to choose a method to log in:
You can go to this website to experience: https://sample-sso.authing.cn/login (opens new window)
User login
Authing will verify whether the user is legitimate. After the verification is passed, the browser will be redirected to the redirect_uri specified when the authorization login request was initiated, and the authorization code code parameter will be passed through URL query.
# 04-Exchange code for token
Exchange token by client_secret_post
If you set the token authentication method to client_secret_post when you configure OIDC on the console, then follow the following method to exchange token.
Here is complete nodejs sample code (opens new window):
let code2tokenResponse;
try {
code2tokenResponse = await axios.post(
"https://yourdomain.authing.cn/oidc/token",
qs.stringify({
code,
client_id: oidcAppId,
client_secret: oidcAppSecret,
grant_type: "authorization_code",
redirect_uri,
}),
{
headers: {
"Content-Type": "application/x-www-form-urlencoded",
},
}
);
} catch (error) {
ctx.body = error.response.data;
return;
}
Example of sending a request using curl:
curl --location --request POST'https://yourdomain.authing.cn/oidc/token' \
--header'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode'code=61yhuOVrgyhKlFTU~bnEKA_fnnz' \
--data-urlencode'client_id=5e37979f7b757ead14c534af' \
--data-urlencode'client_secret=64b517f8de3648091654eb4ee9b479d3' \
--data-urlencode'grant_type=authorization_code' \
--data-urlencode'redirect_uri=https://baidu.com'
Return example:
{
"Access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEifQ.eyJqdGkiOiJQZU41YXg1b3FabGRhcUJUMzQzeUkiLCJzdWIiOiI1Y2U1M2FlYTlmODUyNTdkZDEzMmQ3NDkiLCJpc3MiOiJodHRwczovL29hdXRoLmF1dGhpbmcuY24vb2F1dGgvb2lkYyIsImlhdCI6MTU4MTQyMDk1NywiZXhwIjoxNTgxNDI0NTU0LCJzY29wZSI6Im9wZW5pZCBwcm9maWxlIGF1dGhpbmdfdG9rZW4gZW1haWwgcGhvbmUgYWRkcmVzcyBvZmZsaW5lX2FjY2VzcyIsImF1ZCI6IjVkMDFlMzg5OTg1ZjgxYzZjMWRkMzFkZSJ9.rtpRSL3_U03zXShZUCILquSR_KEDuS-OldWpy8RLztWUNG_tMyrg2g9CG4hC7pJUwmgzZKtp7vsVrj6W0eyo_ehE4KGz9iKnyd46DFbx9W9pi-mieRW5HuVMGL2zvDH8zF467WXET2SVB3LUhFLNmEbxpvjPZ5Ksvbcd7nqHfnUN4-z3SqAvhGWWfcmt7QDFlLtWPw4LzyznEqmM9sDkNiNDnTkjmcjm7yHJR-yv5FvpzQB2kraQVOrrdAixbHf29ihOVO25CrjmgeKemg1vuLNGUcOrr_XWn7xaCSvyAfXrBuRalecW9RA4p_Cp6YslHc_572awekt3kUO2TebUQA",
"expires_in": 3597,
"Id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEifQ.eyJzdWIiOiI1Y2U1M2FlYTlmODUyNTdkZDEzMmQ3NDkiLCJiaXJ0aGRhdGUiOiIiLCJmYW1pbHlfbmFtZSI6IiIsImdlbmRlciI6IiIsImdpdmVuX25hbWUiOiIiLCJsb2NhbGUiOiIiLCJtaWRkbGVfbmFtZSI6IiIsIm5hbWUiOiIiLCJuaWNrbmFtZSI6IiIsInBpY3R1cmUiOiJodHRwczovL3VzZXJjb250ZW50cy5hdXRoaW5nLmNuL2F1dGhpbmctYXZhdGFyLnBuZyIsInByZWZlcnJlZF91c2VybmFtZSI6IiIsInByb2ZpbGUiOiIiLCJ1cGRhdGVkX2F0IjoiIiwid2Vic2l0ZSI6IiIsInpvbmVpbmZvIjoiIiwiY29tcGFueSI6IiIsImJyb3dzZXIiOiIiLCJsb2dpbnNfY291bnQiOjEwMywicmVnaXN0ZXJfbWV0aG9kIjoiZGVmYXVsdDp1c2VybmFtZS1wYXNzd29yZCIsImJsb2NrZWQiOmZhbHNlLCJsYXN0X2lwIjoiMTIxLjIxLjU2LjE3MSIsInJlZ2lzdGVyX2luX3VzZXJwb29sIjoiNWM5NTkwNTU3OGZjZTUwMDAxNjZmODUzIiwibGFzdF9sb2dpbiI6IjIwMjAtMDItMTFUMTE6MzU6MTUuNjk2WiIsInNpZ25lZF91cCI6IjIwMTktMDUtMjJUMTI6MDQ6NTguMjk0WiIsInRva2VuIjoiZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SmtZWFJoSWpwN0ltVnRZV2xzSWpvaWRHVnpkRE5BTVRJekxtTnZiU0lzSW1sa0lqb2lOV05sTlROaFpXRTVaamcxTWpVM1pHUXhNekprTnpRNUlpd2lZMnhwWlc1MFNXUWlPaUkx WXprMU9UQTFOVGM0Wm1ObE5UQXdNREUyTm1ZNE5UTWlmU3dpYVdGMElqb3hOVGd4TkRJd09URTFMQ0psZUhBaU9qRTFPREkzTVRZNU1URjkuM0l0X0NJQTNFbUpoYWcyMW92WjNwd0RfY0owcTVTZkJjSURSZThRX3FoayIsImVtYWlsIjoidGVzdDNAMTIzLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwicGhvbmVfbnVtYmVyIjoiMTMxMTIzNDEyMzQiLCJhZGRyZXNzIjoiIiwiYXRfaGFzaCI6IjV6QnNUOHF4RHc1RmNYdU55UFg4YUEiLCJzaWQiOiJkNmZiOTE5Ny00NmE3LTQ1ZGEtOGVkMC05ODhjZjg0ZjQwZWUiLCJhdWQiOiI1ZDAxZTM4OTk4NWY4MWM2YzFkZDMxZGUiLCJleHAiOjE1ODE0MjQ1NTQsImlhdCI6MTU4MTQyMDk1NywiaXNzIjoiaHR0cHM6Ly9vYXV0aC5hdXRoaW5nLmNuL29hdXRoL29pZGMifQ.VZzqULytIteyBfouww5TsHQ50gEhM06kUWMeDiO3FVFSCW9ys2bFPos5p6LFzliK4Ce09ypOwVQiRnE2gNYsukLvlUPlKDIP_Xk5W19frKi1Z8ImuIPvUqVMKbFutVNS0TfIPCPJVBl8C1j5OXeIs6z0V90QrvyJao6FqVEa3axOHxbhpo1fH2hP04-wkGOp_l10d7RFhGcnPyPnz9-C5X6A4UEsCSDCVw1mDQHxDSFP9OPaB_OlCG_Bi6G-CeLhPa3V5hyIefdBvxC9SIpK-6qY-_BfsNKkBHDVKMb0xodgN2hzn3UTUGBuuoiaB4JhCv72EZ7eiXKIXFz6zVcogA ",
"refresh_token": "DuSPlrUFPAvCZ1WQKarv5MbEsXN",
"scope": "openid profile authing_token email phone address offline_access",
"token_type": "Bearer"
}
id_token will include the information requested by the scope parameter, such as email address, mobile phone number, and parsed id_token:
{
"sub": "5f64afd1ad501364e3b43c1e",
"birthdate": null,
"family_name": null,
"gender": "U",
"given_name": null,
"locale": null,
"middle_name": null,
"name": null,
"nickname": null,
"picture": "https://usercontents.authing.cn/authing-avatar.png",
"preferred_username": "test1",
"profile": null,
"updated_at": "2020-09-27T06:06:29.853Z",
"website": null,
"zoneinfo": null,
"email": "test1@123.com",
"email_verified": false,
"phone_number": null,
"phone_number_verified": false,
"nonce": "EhoXn8m7vy",
"at_hash": "QVtna22pWzdkeSBW3f91pg",
"aud": "5f17a529f64fb009b794a2ff",
"exp": 1601468174,
"iat": 1601464574,
"iss": "http://console.xxx.localhost:3000/oidc"
}
client_secret_basic exchange for token
If you set the token authentication method to client_secret_basic when configuring OIDC on the console, then follow the method below to exchange tokens. (Client_secret_basic uses HTTP Basic authentication mode for authentication.)
The value after the Basic<space> of the Authorization request header is the base64 value of <client_id>:<client_secret>.
Exchange token with none
If you set OIDC in the console and set the authentication method in exchange for token to none, then there is no need to pass client_secret in exchange for token, and the other parameters are the same as the above table.
# 05-Verify the legitimacy of access_token and id_token
# Use App Secret Verification
Authing uses the Secret of the application to sign the token by default (that is, the HS256 algorithm is selected by default when creating the application).
If you use javascript then you can use jsonwebtoken for verification:
const jwt = require('jsonwebtoken');
let decoded = jwt.verify(token, <appSecret>);
If it is in other languages, you need to use app_secret as the HS256 signature parameter on the server to calculate the signature and compare it with the signature in JWT. The pseudo code is as follows:
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
"1133fd20c14e4cc29b6ecb71fb8eb952" // app_secret
);
# Use public key to verify signature
If you use the RS256 signature algorithm, you need to use the public key to verify the signature. Authing will use the application's private key to sign. Please use the public key in https://[application domain name].authing.cn/oidc/.well-known/jwks.json to verify the signature. Both access_token and id_token issued by Authing can be verified with the above public key.
If you use javascript, you can use the jose library to verify the RS256 signature:
const jose = require("jose");
// The following parameter content is to copy the content returned from https://<application domain name>.authing.cn/oidc/.well-known/jwks.json intact
const keystore = jose.JWKS.asKeyStore({
keys: [
{
e: "AQAB",
n:
"O8iCY52uBPOCnBSRCr3YtlZ0UTuQQ4NCeVMzV7JBtH-7Vuv0hwGJTb_hG-BeYOPz8i6YG_o367smV2r2mnXbC1cz_tBfHD4hA5vnJ1eCpKRWX-l6fYuS0UMti-Bmg0Su2IZxXF9T1Cu-AOlpgXFC1LlPABL4E0haHO8OwQ6QyEfiUIs0byAdf5zeEHFHseVHLjsM2pzWOvh5e_xt9NOJY4vB6iLtD5EIak04i1ND_O0Lz0OYbuV0KjluxaxoiexJ8kGo9W1SNza_2TqUAR6hsPkeOwwh-oHnNwZg8OEnwXFmNg-bW4KiBrQEG4yUVdFGENW6vAQaRa2bJX7obn4xCw",
kty: "RSA",
alg: "RS256",
use: "sig",
kid: "TfLOt3Lbn8_a8pRMuessamqj-o3DBCs1-owHLQ-VMqQ",
},
],
});
// The content of issuer in the option is https://<application domain name>.authing.cn/oidc, and the content of audience is the application ID
// id_token is very long, please swipe right ->
const res = jose.JWT.IdToken.verify(
"EyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IlRmTE90M0xibjhfYThwUk11ZXNzYW1xai1vM0RCQ3MxLW93SExRLVZNcVEifQ.eyJzdWIiOiI1ZjcxOTk0NjUyNGVlMTA5OTIyOTQ5NmIiLCJiaXJ0aGRhdGUiOm51bGwsImZhbWlseV9uYW1lIjpudWxsLCJnZW5kZXIiOiJVIiwiZ2l2ZW5fbmFtZSI6bnVsbCwibG9jYWxlIjpudWxsLCJtaWRkbGVfbmFtZSI6bnVsbCwibmFtZSI6bnVsbCwibmlja25hbWUiOm51bGwsInBpY3R1cmUiOiJodHRwczovL2ZpbGVzLmF1dGhpbmcuY28vdXNlci1jb250ZW50cy9waG90b3MvOWE5ZGM0ZDctZTc1Ni00NWIxLTgxZDgtMDk1YTI4ZTQ3NmM2LmpwZyIsInByZWZlcnJlZF91c2VybmFtZSI6InRlc3QxIiwicHJvZmlsZSI6bnVsbCwidXBkYXRlZF9hdCI6IjIwMjAtMDktMzBUMDc6MTI6MTkuNDAxWiIsIndlYnNpdGUiOm51bGwsInpvbmVpbmZvIjpudWxsLCJlbWFpbCI6InRlc3QxQDEyMy5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsInBob25lX251bWJlciI6bnVsbCwicGhvbmVfbnVtYmVyX3ZlcmlmaWVkIjpmYWxzZSwibm9uY2UiOiJFNjViMVFvVVl0IiwiYXRfaGFzaCI6IkIzSWdPWUREYTBQejh2MV85cVpyQXciLCJhdWQiOiI1ZjE3YTUyOWY2NGZiMDA5Yjc5NGEyZmYiLCJleHAiOjE2MDE0NTM1NTgsImlhdCI6MTYwMTQ0OTk1OSwiaXNzIjoiaHR0cHM6Ly9vaWRjMS5hdXRoaW5nLmNuL29pZGMifQ.Z0TweYr9bCdYNJREVdvbJYcjXSfSsSNHBMqxTJeW-bnza0IIpBpEEVxlDG0Res6FZbcVzsQZzfJ9pj_nFgLjZxUUxv7Tpd13Sq_Ykg2JKepPf3-uoFqbORym07QEj4Uln0Quuh094MTb7z6bZZBEOYBac46zuj4uVp4vqk5HtCUSB4ASOAxwi7CeB1tKghISHz6PDcf6XJe_btHdzX1dparxtML-KvPxjpcHlt5emN88lpTAOX7Iq0EhsVE3PKrIDfCkG8XlL5y9TIW2Dz2iekcZ5PV17M35G6Dg2Q07Y_Apr18_oowOiQM5m_EbI90ist8CiqO9kBKreCOLMzub4Q ",
keystore,
{
issuer: "https://oidc1.authing.cn/oidc",
audience: "5f17a529f64fb009b794a2ff",
}
);
console.log(res);
Output result:
{
sub: '5f719946524ee1099229496b',
birthdate: null,
family_name: null,
gender:'U',
given_name: null,
locale: null,
middle_name: null,
name: null,
nickname: null,
picture:'https://files.authing.co/user-contents/photos/9a9dc4d7-e756-45b1-81d8-095a28e476c6.jpg',
preferred_username:'test1',
profile: null,
updated_at: '2020-09-30T07:12:19.401Z',
website: null,
zoneinfo: null,
email:'test1@123.com',
email_verified: false,
phone_number: null,
phone_number_verified: false,
nonce:'E65b1QoUYt',
at_hash:'B3IgOYDDa0Pz8v1_9qZrAw',
aud: '5f17a529f64fb009b794a2ff',
exp: 1601453558,
iat: 1601449959,
iss:'https://oidc1.authing.cn/oidc'
}
# Send token or id_token to the token verification interface provided by Authing for verification
Verify the validity of access_token / id_token online
Authing provides an interface to directly verify the validity of access_token or id_token online.
Reference link
- JWKS Reference Specification (opens new window);
- A website that can check the JWT signature online: https://jwt.io (opens new window);
- Convert between RSA public and private key PEM format and JWK format: https://8gwifi.org/jwkconvertfunctions.jsp (opens new window);
- Generate JWK: https://mkjwk.org (opens new window);
# 06-Use access_token to exchange user information
Developers should exchange access_token for user information on their backend server. If the scope parameter is different when the authorized login is initiated, the returned information will be different. The fields in the returned information depend on the scope parameter. The fields conform to the OIDC specification (opens new window). For the correspondence between the user information field and the scope, please refer to [User Information Corresponding to the Scope Parameters](/authentication /oidc/oidc-params.md#scope-User information corresponding to the parameter).
Use access_token in exchange for user information
Example of request link: https://core.authing.cn/oidc/me?access_token=<access_token>
Return example:
{
"sub": "5f7174df27e0eb9c6d21436d",
"birthdate": null,
"family_name": null,
"gender": "U",
"given_name": null,
"locale": null,
"middle_name": null,
"name": null,
"nickname": null,
"picture": "https://usercontents.authing.cn/authing-avatar.png",
"preferred_username": null,
"profile": null,
"updated_at": "2020-09-28T05:33:15.892Z",
"website": null,
"zoneinfo": null
}
For more field explanation, please refer to [User Information Field Meaning](/authentication/oidc/oidc-params.md#scope-User information corresponding to the parameter.md#User information field meaning).
# 07-Refresh token
Use refresh_token to refresh the user's access_token and id_token.
To use the refresh token function, you need to enter Control Panel > App > App List, find your application, click "Configuration", and check refresh_token in the application configuration tab.
refresh_token
Note ⚠️⚠️⚠️: When initiating a login request, you must fill in the correct URL query parameter, only check refresh_token and Authorization login parameter error or Direct input application authentication address, Authing** Will not return ** any refresh_token. offline_access must be included in the scope parameter, and the value of the prompt parameter must be consent. Example of login request that can return refresh_token:
https://example.authing.cn/oidc/auth?client_id=5c9b079883e333d55a101082&redirect_uri=https://example.com&scope=openid profile offline_access&response_type=code&prompt=consent&state=235345
# 09-Verify token status
09-Check token status
Only access_token and refresh_token can check the status, id_token cannot be checked.
# Use implicit mode (Implicit Flow)
OIDC implicit mode does not return the authorization code code, but directly sends access_token and id_token to the front end of the callback address through URL hash, and the backend cannot be obtained return here The value of because the URL hash will not be sent directly to the backend.
# Configure OIDC application in the console
Go to Control Panel> Application> Application List, find your application, click "Configuration", in the application configuration tab, find the authorization mode, check the implicit mode, and click Check id_token token and id_token in the return type below.
id_token token / id_token
# Initiate authorization
Initiating the implicit mode authorization login need to splice a URL and allow the end user to access it in the browser, **cannot directly enter **authentication address domain name. The specific parameters are as follows:
| Parameter name | Meaning |
|---|---|
| client_id | Application ID. |
| redirect_uri | Callback link. After the user is successfully authenticated by OP, OP will send id_token and access_token to this address in the form of URL hash. This value must appear in the callback address of the console configuration, otherwise the OP is not allowed to call back to this address. When the implicit mode is enabled, it is recommended to use the https address for all **redirect_uri configured by the console, otherwise the access_token will be transmitted in plaintext, causing security risks. If you want to use an http address, please turn on the "The implicit mode callback link is not mandatory to https" in the console. |
| scope | The requested permission must include openid. If you need to get your phone number and email, you need to include phone email; multiple scopes should be separated by spaces. At the same time, id_token will contain related fields. Implicit mode does not support returning refresh_token, so the offline_access field is invalid. |
| response_type | Return type, which can be id_token, id_token token. Used to specify OP to return id_token and access_token. Refer to OIDC specifications (opens new window). |
| prompt | can be none, login, consent or select_account, which specifies the interaction mode between OP and End-User. Refer to OIDC specification (opens new window). |
| state | A random string used to prevent CSRF attacks. If the state value in the response is different from the state value set before sending the request, it means that it is under attack. |
| nonce | A random string used to prevent Replay attacks, required in implicit mode. |
Suppose you create an OIDC application with the domain name example, then the URL for initiating the implicit mode OIDC authorization login is:
GET https://example.authing.cn/oidc/auth?client_id=5ca765e393194d5891db1927&redirect_uri=https://example.com&scope=openid profile&response_type=id_token token&state=6223573295&nonce=1831289
# Get id_token and access_token
id_token and access_token will be passed in the form of URL hash, example of link after redirection:
https://authing.cn/#id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1Y2QwMjZlZjNlZDlmOTRkODBmZTM2YWUiLCJub25jZSI6IjE4MzEyODkiLCJzaWQiOiI4YzgzN2I5My01OTNlLTQzZjctYWMzNC0yYjRmZDU3ZGFhMTciLCJhdF9oYXNoIjoiVFFtbFlEVTVPZGF1Zjl0U0VKdHY5USIsInNfaGFzaCI6Ind3SDNXclV2b0hiSUp5TWVZVHU4bHciLCJhdWQiOiI1ZDAxZTM4OTk4NWY4MWM2YzFkZDMxZGUiLCJleHAiOjE1NjA0MDkzNjgsImlhdCI6MTU2MDQwNTc2OCwiaXNzIjoiaHR0cHM6Ly9vYXV0aC5hdXRoaW5nLmNuL29hdXRoL29pZGMifQ.T9M0s6rk4Teq6VOOBRIElgHK9KyM3q0ZJj2aS0VD_Fw&access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiI3OE9XcVJNVXJEUXpMMXpHVzVtUWoiLCJzdWIiOiI1Y2QwMjZlZjNlZDlmOTRkODBmZTM2YWUiLCJpc3MiOiJodHRwczovL29hdXRoLmF1dGhpbmcuY24vb2F1dGgvb2lkYyIsImlhdCI6MTU2MDQwNTc2OCwiZXhwIjoxNTYwNDA5MzY4LCJzY29wZSI6Im9wZW5pZCBwcm9maWxlIiwiYXVkIjoiNWQwMWUzODk5ODVmODFjNmMxZGQzMWRlIn0.mR0MZDwlZWGRMsAZjQ27sDFFqYoDgZ6WHTK4C7JbML4&expires_in=3600&token_type=Bearer&state=jazz&session_state=26ec053be9f47d68dc430f84b97efb1095469fe10169a9e00ef4092718714b8b
The process of exchanging user information is the same as the authorization code mode.
Why is the information in the URL hash instead of the query? Because the hash content will not be sent directly to the server, avoid id_token and access_token from being stolen.
Reference materials:
[Scope and user information correspondence table] (oidc-params.md#scope- user information corresponding to the parameter)
# Use hybrid mode (Hybrid Flow)
The mixed mode supports returning code, access_token and id_token to the front end of the callback address at the same time, and they are all passed in the form of URL Hash, which cannot be received directly by the back end because the URL hash will not be sent directly to the server .
# Configure OIDC application in the console
Go to Control Panel> Applications> Application List, find your application, click "Configuration", in the application configuration tab, find the authorization mode, select authorization_code and implicit, And check code id_token token, code id_token, code token in the return type below.
code, access_token and id_token
# Initiate authorization
Initiating authorization requires splicing a URL for authorization and allowing end users to access it in a browser. You cannot directly access the authentication address domain name. The specific parameters are as follows:
| Parameter | Description |
|---|---|
| client_id | Application ID. |
| redirect_uri | Callback link. After the user is successfully authenticated by the OP, the OP will send the code, id_token, and access_token to this address in the form of URL hash. This value must appear in the callback address of the console configuration, otherwise the OP is not allowed to call back to this address. When using mixed mode, it is recommended to use the https address for all the redirect_uri configured in the console, otherwise the access_token will be transmitted in plaintext, causing security risks. If you want to use an http address, please turn on the "The implicit mode callback link is not mandatory to https" in the console. |
| scope | The requested permission must include openid. If you need to get your mobile phone number and email, you need to include phone email. Please separate multiple scopes with spaces. At the same time, id_token will contain related fields. If you need to refresh the token, you need to have the offline_access parameter, and at the same time, the response_type parameter must contain code**,** and use code to exchange token**, and refresh_token will be returned in the result of subsequent code exchange token. |
| response_type | Return type, here is code id_token token. Used to specify OP return code, id_token and access_token. Refer to OIDC specifications (opens new window). |
| prompt | can be none, login, consent or select_account, which specifies the interaction mode between OP and End-User. Refer to OIDC specification (opens new window). |
| state | A random string used to prevent CSRF attacks. If the state value in the response is different from the state value set before sending the request, it means that it is under attack. |
| nonce | A random string used to prevent Replay attacks. It is required in mixed mode. |
Suppose you create an OIDC application with the domain name example, then the authorized URL is:
GET https://example.authing.cn/oidc/auth?client_id=5ca765e393194d5891db1927&redirect_uri=https://example.com&scope=openid profile&response_type=code id_token token&state=23758235&nonce=1831289
The code, access_token and id_token are passed through the URL hash, and the link example after the jump:
https://example.com/#code=pIY83Jl_bcerNN9Wt57Sq0TAjTr&id_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InIxTGtiQm8zOTI1UmIyWkZGckt5VTNNVmV4OVQyODE3S3gwdmJpNmlfS2MifQ.eyJzdWIiOiI1YzlmNzVjN2NjZjg3YjA1YTkyMWU5YjAiLCJub25jZSI6IjE4MzEyODkiLCJzaWQiOiIxOTdlOGExMy0wMzE4LTRkZDEtYjQ3Mi0xZjI0MDk5ZTUzOWYiLCJhdF9oYXNoIjoiUFlXaTFER29jRlotYmlYd0d5WXlpZyIsImNfaGFzaCI6Ik4yUmkyUFpidktYdXRmdGhZbUhrM2ciLCJzX2hhc2giOiJ3d0gzV3JVdm9IYklKeU1lWVR1OGx3IiwiYXVkIjoiNWNhNzY1ZTM5MzE5NGQ1ODkxZGIxOTI3IiwiZXhwIjoxNTU0NjE1NjcyLCJpYXQiOjE1NTQ2MTIwNzIsImlzcyI6Imh0dHBzOi8vYXV0aGluZy5jbiJ9.a--JC_6CyUi0Z7z3DCKT51wJkKT7MmtlVHhrNujhxHCfgQqzqS3wMxVj6oEe_cfjVQNgJ-Xe1oiL8uMAxVN-cM1Ra1JQcavUujua2IxxtG4Nkh84rTukqsrPfuNhNO7MRP6Fa9qIIdKeKkQKyh1zBKE6322zK_ECdfGd2sWdqqXiQyJXg6ODhPZDidsGuluV3bZiAY3brMSMmh6QC99StOP5ZwSKtlRMyYE3MIRWsQ4W2HkHBrk67T_scQ6XN6mdBKi2OZW-E7fXeyVwH-ibWDzlUpmFSaj3a-WbkDe3nfCv8MHj439aJNU-AXfIgLsckvCO5_dJOUWGHg6hemT9bw&access_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InIxTGtiQm8zOTI1UmIyWkZGckt5VTNNVmV4O VQyODE3S3gwdmJpNmlfS2MifQ.eyJqdGkiOiIxUzgyaUtSdXFlWW1DUmFrMFl1S0kiLCJzdWIiOiI1YzlmNzVjN2NjZjg3YjA1YTkyMWU5YjAiLCJpc3MiOiJodHRwczovL2F1dGhpbmcuY24iLCJpYXQiOjE1NTQ2MTIwNzIsImV4cCI6MTU1NDYxNTY3Miwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSIsImF1ZCI6IjVjYTc2NWUzOTMxOTRkNTg5MWRiMTkyNyJ9.tHwxiH5QXXA46Y4mIwcBck3uDArMj5TMGEBAQ8Eeln6oFbwBY3aS5cSV6e3anZDwKZrdgrdFlyj9-Bl1T5V1rNJK-Xz_aFnM6XxyO1jSHcn-6KXGwmz68D50VIHior39cuoj9OXbNCei5RVghjh2cRT3SenYki7UeJBgmfQA6l2aZZpBrn9aphXr9OoPS47T59I0Ynn2yMIYIMDOX7hh8E5oV1hrK3hyjAvp3ghmzyRfj2BlG9rBo1hd_d5E8x6OIzNdvPKXwVASJZRxov2Dx0ma36zxzSObyXgCloUv2KlbmL9-Wj8d3H6FhHC75DLfJYx-uRgNqW7CFKGeRkPjkQ & expires_in = 3600 & token_type = Bearer & state = jazz & session_state = 101666b6b70cfb4406ad9c0c906039de39776140e66e48acdb63ab8acb309701
The process of exchanging user information is the same as the authorization code mode.
Reference materials:
[Scope and user information correspondence table] (oidc-params.md#scope- user information corresponding to the parameter)
# Use Password mode
This mode is not recommended, try to use other modes.
# Configure OIDC application in the console
Enter Console (opens new window) > Application > Application List, find your application, click "Configuration", Check password in the application configuration. Click "Save".
password
Use login credentials in exchange for token
In Password mode, you can directly use the user's login credentials to exchange for OIDC token
User ID field "email, phone, username" is mutually exclusive, you cannot pass in any combination of two or more of them at the same time.
Reference Materials
- [Scope and user information correspondence table] (oidc-params.md#scope-parameter corresponding user information)
- When to use Password mode? 「Video」 (opens new window)
- Password mode is only used for forward compatibility with "video" (opens new window)
# Use authingToken mode(deprecated)
This mode is now only compatible with users of older versions of Authing, and you should not use this mode.
# Configure OIDC application in the console
Enter Console (opens new window) > Application > Application List, find your application, click "Configuration", Check authingToken in the application configuration. Click "Save".
authingToken
Use Authing Token in exchange for OIDC token
In the authingToken mode, the user's Authing Token can be used directly in exchange for OIDC token.
# Exit SSO
If you use OAuth 2.0, OIDC or SAML to achieve single sign-on, you can visit the following address to let users log out at OP:
https://<your domain name>.authing.cn/login/profile/logout?redirect_uri=<callback address after logout>
redirect_uri is the address you want to return to after logging out.
If you want to log out of SSO on the backend, you can maintain a Cookie-Session state by yourself, and then set the cookie to expire.