In the previous article, we introduced the OIDC authorization code mode (click the link below to view), this time we will focus on the introduction of the authorization code + PKCE mode (Authorization Code With PKCE), so that your system can quickly access A standard system for user authentication.
Why there is a PKCE mode:
PKCE is the abbreviation of Proof Key for Code Exchange. PKCE is a method for enhancing the security of authorization code mode, which can prevent malicious applications from obtaining access tokens by intercepting authorization codes and redirecting URIs. PKCE guarantees user security by sending a random string (code_verifier) and its SHA-256 hash (code_challenge) with the authorization request, ensuring that the access token can only be used by applications with the corresponding code_verifier.
[OAuth 2.0 protocol extension] PKCE extension protocol: in order to solve the authorization security problem of public clients
The "object-oriented" public client itself has no ability to save key information (malicious attackers can view the client's key client_secret through decompilation and other means, and can exchange the authorization code code for access_token. At this point, malicious applications Then you can request the resource server with the token)
"Principle" The PKCE protocol itself is an extension of OAuth2.0, which is roughly the same as the previous authorization code process, the difference is that when requesting the authorize endpoint of the authorization server, additional parameters code_challenge and code_challenge_method are required; to the token endpoint When requested, an additional code_verifier parameter is required. Finally, the authorization server will compare and verify these three parameters, and issue a token after passing.
01. Authorization Code With PKCE Mode (Authorization Code With PKCE)
If your application is a SPA front-end application or mobile App, it is recommended to use the authorization code + PKCE mode to complete user authentication and authorization. Authorization code + PKCE mode is suitable for scenarios where keys cannot be stored securely (such as front-end browsers)
Let's explain code_verifier and code_challenge
For each OAuth/OIDC request, the client will first create a code verifier code_verifier
code_verifier: In the range of [AZ] / [az] / [0-9] / "-" / "." / "_" / "~", generate a random string of 43-128 digits.
code_challenge: It is obtained by converting code_verifier through code_challenge_method such as sha256.
In the vernacular, the authentication means that the user carries the encrypted code_challenge. When the user successfully passes the code to obtain the Token, the way for the client to prove itself is to send the original text of the code_verifier, and the authentication center passes the code_verifier + code_challenge_method to convert, if the final result matches code_challenge, return Token, otherwise reject.
1.1 Overall process
Overall, there are the following processes:
| 1. The user clicks Login. |
| 2. In your application, generate code_verifier and code_challenge. |
| 3. Splicing the login link (including code_challenge) to jump to Authing to request authentication. |
| 4. Authing finds that the user is not logged in, redirects to the authentication page, and requires the user to complete the authentication. |
| 5. The user completes the authentication in the browser. |
| 6. The Authing server sends the authorization code (code) to your application front end through redirection through the browser. |
| 7. Your application sends the authorization code (code) and code_verifier to Authing to request a Token. |
| 8. Authing verification code, code_verifier and code_challenge. |
| 9. If the verification is passed, Authing returns AccessToken, IdToken and optional RefreshToken. |
| 10. Your application now knows the identity of the user, and then use AccessToken to exchange user information, call the API of the resource party, etc. |
1.2 Prepare to connect
1.2.1 Overall process
You need to create an application in Authing first :
Configure the login callback and logout callback, and configure it as the address of your actual project. We configure localhost here for testing.
If you want to match multiple login/logout callbacks
You can use '*' for wild carding, and the login/logout callback can be in the following format
In the protocol configuration, we check authorization_code and use code as the return type, as shown in the following figure:
PKCE mode uses code_verifier to exchange Token, so it needs to configure the way to get Token as null
1.3 Access test
1.3.1 List of required calling interfaces
| GET${host}/oidc/auth Initiate login (splicing your initiating login address) |
| POST${host}/oidc/token Take Token |
| GET${host}/oidc/me Get user information |
| POST ${host}/oidc/token/introspection Verification Token |
| POST${host}/oidc/token Revamp Token |
| POST ${host}/oidc/revocation to revoke Token |
| GET ${host}/session/end logout |
1.3.2 Run in Postman required calling interface list
1.3.3 Initiate login
GET${host}/oidc/auth
This is the starting point for the browser-based OIDC, which requests to authenticate the user and returns an authorization code to the redirect_uri you specify upon successful authentication.
Generate code_challenge and code_verifier
generate online
https://tonyxu-io.github.io/pkce-generator/
generate offline
First, we need to generate a code_challenge and code_verifier, the following is the code_verifier and code_challenge scripts needed to generate PKCE using JavaScript language:
// 生成随机字符串
function generateRandomString(length) {
var result = '';
var characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
var charactersLength = characters.length;
for (var i = 0; i < length; i++) {
result += characters.charAt(Math.floor(Math.random() * charactersLength));
}
return result;
}
// 生成 code_verifier
var codeVerifier = generateRandomString(128);
// 对 code_verifier 进行 SHA-256 编码，并将其转换为 base64url 格式的 code_challenge
var sha256 = new jsSHA("SHA-256", "TEXT");
sha256.update(codeVerifier);
var codeChallenge = btoa(String.fromCharCode.apply(null, new Uint8Array(sha256.getHash("ARRAYBUFFER"))))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
// 将 code_verifier 和 code_challenge 用对象形式返回
var pkce = {
codeVerifier: codeVerifier,
codeChallenge: codeChallenge
};
The above code uses the jsSHA library to calculate the SHA-256 hash value, and uses base64url encoding to convert the hash value into code_challenge. You can copy the above code into your JavaScript code and use pkce.codeVerifier and pkce.codeChallenge to call OAuth 2.0 authorization request.
example
code_verifier:
4aHg5fN1AGdbnBAfVKMf9ZMK4PUOBTwQSKKk9V8wYXOFYDZklMl7dzDUhnQi4sYhzGb6PWCkNQqLP70K1DNOneEDq8iyASepAdGjGBBmCs4BGCDDJNwLrGpnJEfmrI66
The length of code_verifier is 43 ~ 128, we generate 128 bits
code_challenge:
OhMk95M9qWkKd06--utVtRzQh8Y0Qtqo4cPqqzMJyMw
Initiate login address (open in browser)
https://{host}/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=6e187def-1a19-4067-8875-653f024d5a9f&client_id={client_id}&state=1676881862&code_challenge={code_challenge}&code_challenge_method=S256
Experience address
Parameter 
description
1.3.4 Get Token
POST${host}/oidc/token
After the user completes the login operation on the Authing side, Authing will call back the generated code as a parameter to the redirect_uri address. At this time, the corresponding access token access_token can be obtained through the code-for-token interface
request parameters
request example
curl --location --request POST 'https://{host}/oidc/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'redirect_uri={发起登录时指定的 redirect_uri}' \
--data-urlencode 'code={/oidc/auth 返回的code}' \
--data-urlencode 'code_verifier={code_verifier}'
Example Response (Success)
{
"scope": "openid username email phone offline_access profile",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImVtSzBGbVRIa0xlQWFjeS1YWEpVT3J6SzkxV243TkdoNGFlYUVlSjVQOUUifQ.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJzY29wZSI6Im9wZW5pZCB1c2VybmFtZSBlbWFpbCBwaG9uZSBvZmZsaW5lX2FjY2VzcyBwcm9maWxlIiwiaWF0IjoxNjc2MzY2OTE0LCJleHAiOjE2Nzc1NzY1MTQsImp0aSI6ImVmVU04enNrbl92LXYzeXZfbDVHRV9fQ2JEY0NNZDhEVDFnYVI0bHRqcHAiLCJpc3MiOiJodHRwczovL29pZGMtYXV0aG9yaXphdGlvbi1jb2RlLmF1dGhpbmcuY24vb2lkYyJ9.E3gAYzCQbJmrtM5zl91OPHm2YPnDxzRejw75oVMF1tLqCS0trj6CSBxyxP3Z9t6Eb_oAu1f_3I6XC3KC-l0DTM6q7_R2rnW4LWlik2rDCLuGpG0FqFScLZhwafmrPsVn93yaBQfEEoaLviqKhj3DgOymKqHZzFG3taaz2k_pWsxt4z97DtKjRTiqyMvcSfHsVrjSKELaC-5S_PHPWcQ70iX85IwUb6i5ldZGxYmODCvChNC9p4D4IOT3atvyEHgBTmjA9ZKI-T7hCVHSO91WZY3l1p4iWdi6KdP1oMGTy8WbmUHG9SiWO1Efh_9I5ZpRzVNWXINLv-lZ0d2aZKjg2w",
"expires_in": 1209600,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJpYXQiOjE2NzYzNjY5MTQsImV4cCI6MTY3NzU3NjUxNCwiaXNzIjoiaHR0cHM6Ly9vaWRjLWF1dGhvcml6YXRpb24tY29kZS5hdXRoaW5nLmNuL29pZGMiLCJub25jZSI6IjhiYjg3MjdhLWU1MGUtNDUzOC05ZmZmLWZhOTFlNWQ0Y2MwYSIsIm5hbWUiOm51bGwsImdpdmVuX25hbWUiOm51bGwsIm1pZGRsZV9uYW1lIjpudWxsLCJmYW1pbHlfbmFtZSI6bnVsbCwibmlja25hbWUiOm51bGwsInByZWZlcnJlZF91c2VybmFtZSI6bnVsbCwicHJvZmlsZSI6bnVsbCwicGljdHVyZSI6Imh0dHBzOi8vZmlsZXMuYXV0aGluZy5jby9hdXRoaW5nLWNvbnNvbGUvZGVmYXVsdC11c2VyLWF2YXRhci5wbmciLCJ3ZWJzaXRlIjpudWxsLCJiaXJ0aGRhdGUiOm51bGwsImdlbmRlciI6IlUiLCJ6b25laW5mbyI6bnVsbCwibG9jYWxlIjpudWxsLCJ1cGRhdGVkX2F0IjoiMjAyMy0wMi0xNFQwOToyNjoyOC4wNjhaIiwiZW1haWwiOm51bGwsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwicGhvbmVfbnVtYmVyIjoiMTg1MTY4Mjk5OTUiLCJwaG9uZV9udW1iZXJfdmVyaWZpZWQiOnRydWUsInVzZXJuYW1lIjpudWxsfQ.GweoWBCEyHQGP6G9ohbfBMUMALlbZMM9hRAes1De7BM",
"refresh_token": "KanvCEmonS_FgCRdFftOCwka2f8Qjj4tcsIfJF-VC1W"
}
Example response (failed)
{
"error": "invalid_grant",
"error_description": "授权码无效或已过期"
}
1.3.5 List of required calling interfaces
GET${host}/oidc/me 获取用户信息
This endpoint is the OIDC Get User endpoint, which can get information about the currently logged-in user through AccessToken.
request parameters
request example
curl --location --request GET 'https://{host}/oidc/me?access_token={access_token}'
Example Response (Success)
{
"name": null,
"given_name": null,
"middle_name": null,
"family_name": null,
"nickname": null,
"preferred_username": null,
"profile": null,
"picture": "https://files.authing.co/authing-console/default-user-avatar.png",
"website": null,
"birthdate": null,
"gender": "U",
"zoneinfo": null,
"locale": null,
"updated_at": "2023-02-14T09:26:28.068Z",
"email": "[email protected]",
"email_verified": true,
"phone_number": "185xxxx9995",
"phone_number_verified": true,
"username": "neo",
"sub": "63eb53c441a5c2f05f24bb03"
}
Example response (failed)
{
"error": "invalid_grant",
"error_description": "Access Token 无效"
}
1.3.6 Verify Token
POST${host}/oidc/auth
This endpoint accepts access_token, id_token, refresh_token and returns a boolean indicating if it is active or not. If the token is active, additional data about the token will also be returned. A token is considered inactive if it is invalid, expired, or revoked.
access_token can be signed with RS256 signature algorithm or HS256 signature algorithm. Here is the difference between the two signature algorithms:
RS256 is a digital signature algorithm using the RSA algorithm, which uses a public/private key pair to encrypt and authenticate information. Tokens generated with RS256 signatures are more secure than tokens generated with HS256 signatures because signing with an RSA key pair provides a higher level of protection. Tokens using the RS256 signature algorithm can be verified using a public key, which can be obtained through the JWK endpoint.
HS256 is a digital signature algorithm using a symmetric key. It uses the same key for signing and verification. The HS256 signature algorithm is faster in performance than the RS256 signature algorithm because it uses a symmetric key instead of an RSA public/private key pair for signing and verification. Tokens using the HS256 signature algorithm can be verified by a shared secret (application key).
In practical applications, the RS256 algorithm is more secure, but it also consumes more resources. If the system requires high performance, you can choose the HS256 signature algorithm.
There are two ways to verify Token
Local authentication and online authentication using Authing. We recommend validating the JWT Token locally, as it saves your server bandwidth and speeds up validation. You can also choose to send the Token to the verification interface of Authing, and Authing will verify and return the result, but this will cause network delay, and there may be slow requests when the network is congested.
The following is a comparison of the advantages and disadvantages of local verification and online verification:
online verification
It should be noted that id_token cannot be verified online at present, because id_token is just an identifier. If you need to verify id_token, you need to verify it offline
request parameters
request example
curl --location --request POST 'https://{host}/oidc/token/introspection' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token={ token }' \
--data-urlencode 'token_type_hint={token_type_hint}'
Verification access_token response example (verification passed)
{
"active": true,
"sub": "63eb53c441a5c2f05f24bb03",
"client_id": "63eb4585156d977101dd3750",
"exp": 1677648467,
"iat": 1676438867,
"iss": "https://oidc-authorization-code.authing.cn/oidc",
"jti": "ObgavGBUocr1wsrUvtDLHmuFSgoebxsiOY4JNRqIhaQ",
"scope": "offline_access username profile openid phone email",
"token_type": "Bearer"
}
Verification access_token response example (verification failed)
{
"active": false
}
Verification refresh_token response example (verification passed)
{
"active": true,
"sub": "63eb53c441a5c2f05f24bb03",
"client_id": "63eb4585156d977101dd3750",
"exp": 1679030867,
"iat": 1676438867,
"iss": "https://oidc-authorization-code.authing.cn/oidc",
"jti": "6F2TO1v1YZ1_N7I3jXYHjK-vZzKtlD0IiP5KPoUFUCQ",
"scope": "offline_access username profile openid phone email"
}
Verification refresh_token response example (verification failed)
{
"active": false
}
Offline verification
Reference documents (Authing Developer Documentation):
https://docs.authing.cn/v2/guides/faqs/how-to-validate-user-token.html#%E6%9C%AC%E5%9C%B0%E9%AA%8C%E8%AF%81
Let's briefly say that if you use offline verification, you should verify the token according to the following rules
1. Format verification - verify whether the token format is JWT format
2. Type verification - verify whether the token is the target token type, such as access_token, id_token, refresh_token
3. Issuer verification - verify whether the token is issued by a trusted issuer
4. Signature verification - verify whether the token signature is issued by the issuer to prevent forgery
5. Validity period check - check whether the token is within the validity period
6. claims verification - whether it is in line with expectations
Sample code
The following is a sample Java code that can be used to locally verify the access_token issued by OIDC RS256 and HS256
import com.nimbusds.jose.JWSObject;
import com.nimbusds.jwt.JWTClaimsSet;
import com.nimbusds.jwt.SignedJWT;
import java.net.URL;
import java.text.ParseException;
import java.util.Date;
public class OIDCValidator {
private static final String ISSUER = "https://your-issuer.com";
private static final String AUDIENCE = "your-client-id";
private final URL jwkUrl;
public OIDCValidator(final URL jwkUrl) {
this.jwkUrl = jwkUrl;
}
public JWTClaimsSet validateToken(final String accessToken) throws ParseException {
final SignedJWT signedJWT = SignedJWT.parse(accessToken);
if (signedJWT == null) {
throw new RuntimeException("Access token is null or empty");
}
final JWTClaimsSet claims = signedJWT.getJWTClaimsSet();
if (claims == null) {
throw new RuntimeException("No claims present in the access token");
}
if (!claims.getIssuer().equals(ISSUER)) {
throw new RuntimeException("Invalid issuer in access token");
}
if (!claims.getAudience().contains(AUDIENCE)) {
throw new RuntimeException("Invalid audience in access token");
}
final JWSObject jwsObject = signedJWT.getJWSObject();
if (jwsObject == null) {
throw new RuntimeException("No JWS object found in the access token");
}
// Fetch the JWKs from the JWK set URL
final JWKSet jwkSet = JWKSet.load(jwkUrl);
final JWK jwk = jwkSet.getKeyByKeyId(jwsObject.getHeader().getKeyID());
if (jwk == null) {
throw new RuntimeException("No JWK found for the access token");
}
if (!jwsObject.verify(jwk.getKey())) {
throw new RuntimeException("Invalid signature in access token");
}
if (claims.getExpirationTime() == null || claims.getExpirationTime().before(new Date())) {
throw new RuntimeException("Expired access token");
}
return claims;
}
}
This code uses the Nimbus JOSE+JWT library to parse and validate JWT tokens. It verifies the access_token with the specified issuer and audience values, and verifies the format, type, signature, expiration and issuer of the claims in the JWT. If any validation errors occur, a RuntimeException will be thrown. When using it, you need to pass in the corresponding JWK URL and access_token for calling, for example:
final URL jwkUrl = new URL("https://your-issuer.com/.well-known/jwks.json");
final OIDCValidator validator = new OIDCValidator(jwkUrl);
final String accessToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyMzkwMjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c";
final JWTClaimsSet claims = validator.validateToken(accessToken);
This example only verifies the RS256 and HS256 signature algorithms.
1.3.7 Refresh Token
POST${host}/oidc/token
This function is used for the refresh operation of the user token, and the refresh_token needs to be obtained first in the token acquisition phase.
request parameters
request parameters
curl --location --request POST 'https://{host}/oidc/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'refresh_token={刷新令牌}' \
--data-urlencode 'grant_type=refresh_token'
Response example (success)
{
"refresh_token": "6F2TO1v1YZ1_N7I3jXYHjK-vZzKtlD0IiP5KPoUFUCQ",
"scope": "offline_access username profile openid phone email",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImVtSzBGbVRIa0xlQWFjeS1YWEpVT3J6SzkxV243TkdoNGFlYUVlSjVQOUUifQ.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJzY29wZSI6Im9mZmxpbmVfYWNjZXNzIHVzZXJuYW1lIHByb2ZpbGUgb3BlbmlkIHBob25lIGVtYWlsIiwiaWF0IjoxNjc2NDQ0MjY4LCJleHAiOjE2Nzc2NTM4NjgsImp0aSI6IkEtZUlQYkJ5N3lJLTliUmp1RnJHeXNCSXdjbWtOUl9WalpYODB2aU05VFkiLCJpc3MiOiJodHRwczovL29pZGMtYXV0aG9yaXphdGlvbi1jb2RlLmF1dGhpbmcuY24vb2lkYyJ9.Kk3jSK5BSUEDVTQMdMAdG5cBCxZt31vQiD-XYHNA84Gd3Mo8eDLcQpjMEzQ8HJ4_b9IgMOz5ydXz0zAQ6AjLMW3Rl49qhTGDB7Kq7tHTFmDO8itoO2LQTCLPCPtP3TkoOgptlFD_sd32nefH-HojNhuqwKw469Byw3xnW5xEs3wSuOoUdHwR2n9j1T1Zgp3e90xmBjbtbofQE1z0IWtCnrfJ9ujWsKXoN_7OAXbCTa-Ak_DhgLHU7xutQaaBOgD28lLLT5xclgBWfv7Leyx_kBnVGT5Jvo1tfA6AUEp6wJO4GUBzsijLefI04VDzBGypNuFJlw_jOhSp-SWxJjQSwQ",
"expires_in": 1209600,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI2M2ViNTNjNDQxYTVjMmYwNWYyNGJiMDMiLCJhdWQiOiI2M2ViNDU4NTE1NmQ5NzcxMDFkZDM3NTAiLCJpYXQiOjE2NzY0NDQyNjgsImV4cCI6MTY3NzY1Mzg2OCwiaXNzIjoiaHR0cHM6Ly9vaWRjLWF1dGhvcml6YXRpb24tY29kZS5hdXRoaW5nLmNuL29pZGMiLCJuYW1lIjpudWxsLCJnaXZlbl9uYW1lIjpudWxsLCJtaWRkbGVfbmFtZSI6bnVsbCwiZmFtaWx5X25hbWUiOm51bGwsIm5pY2tuYW1lIjpudWxsLCJwcmVmZXJyZWRfdXNlcm5hbWUiOm51bGwsInByb2ZpbGUiOm51bGwsInBpY3R1cmUiOiJodHRwczovL2ZpbGVzLmF1dGhpbmcuY28vYXV0aGluZy1jb25zb2xlL2RlZmF1bHQtdXNlci1hdmF0YXIucG5nIiwid2Vic2l0ZSI6bnVsbCwiYmlydGhkYXRlIjpudWxsLCJnZW5kZXIiOiJVIiwiem9uZWluZm8iOm51bGwsImxvY2FsZSI6bnVsbCwidXBkYXRlZF9hdCI6IjIwMjMtMDItMTRUMDk6MjY6MjguMDY4WiIsImVtYWlsIjpudWxsLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsInBob25lX251bWJlciI6IjE4NTE2ODI5OTk1IiwicGhvbmVfbnVtYmVyX3ZlcmlmaWVkIjp0cnVlLCJ1c2VybmFtZSI6bnVsbH0.DGoJrzkgti44zw-MotVM1KpLxbJTzc5pfh-xYun_xDQ"
}
Response example (failed)
{
"error": "invalid_grant",
"error_description": "Refresh Token 无效或已过期"
}
1.3.8 Withdraw Token
POST${host}/oidc/auth
Remove access_token / refresh_token .
request parameters
request example
curl --location --request POST 'https://{host}/oidc/token/revocation' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token= {token}' \
--data-urlencode 'token_type_hint={token_type_hint}'
Response example (success)
HTTP 200 OK
Response example (failed)
{
"error": "xxxx",
"error_description": "xxxx"
}
1.3.9 User Logout
GET${host}/oidc/session/end
Use this action to log out a user by deleting their browser session.
post_logout_redirect_uri can specify the address to redirect after performing logout. Otherwise, the browser will redirect to the default page
request parameters
Request example (browser access)
GET https://oidc-authorization-code.authing.cn/oidc/session/end?id_token_hint={id_token}&post_logout_redirect_uri=http://localhost:8080/&state=1676452381
02. Summary of this chapter
In this chapter, we introduce the access process of the OIDC authorization code mode and the calling method of related interfaces. For Xiaobai, you may need to run through the process as a whole to get familiar with it. We also recommend that you fork our postman collection and run the process. For PKCE mode, you It's basically mastered.
Next, we will also introduce OIDC's authorization code + PKCE process and the way to access Authing. You need to have a certain understanding of the authorization code mode process.
Past exciting content
What is event-driven (EDA)? Why is it a major driver in the tech space?
Authing combines APISIX to realize a unified and configurable API authority gateway
