⚠️ ATTENTION !

Make sure your authorization service can be accessed normally, otherwise the request may fail
Make sure your relevant request address and URL information are filled in correctly, otherwise the request will not be able to proceed normally
Considering the differences in authorization server requests and return data of different companies, you need to fill in the request template when configuring. The template supports five placeholders: {ClientId}, {ClientSecret}, {Code}, {AccessToken}, {AccessTokenType}. You need to fill in the correct placeholders in the template. Only one level of nesting is supported, not multiple levels of nesting.
The Content-Type of the HTTP request is application/json. When obtaining user information, the HTTP Header will automatically carrythe Authorization: {AccessToken} or Authorization: Bearer {AccessToken} key- value pair.

1. Business Request Process

descript

2. Placeholder Description

Placeholder	meaning
{ClientId}	Your company's authorization server generates the ClientId In [Login-free Configuration], the placeholder format used in your request parameters, return parameters, and URL must be:{ClientId}
{ClientSecret}	Your company's authorization server generates a ClientSecret In [Login-free Configuration], the placeholder format used in your request parameters, return parameters, and URLs must be:{ClientSecret}
{Code}	The code that your company's authorization server calls back after the user authorizes In [Login-free Configuration], the format of the placeholders used in your request parameters, return parameters, and URLs must be:{Code}
{AccessToken}	The token obtained by calling the configured [ Get Token URL ] through the [code] callback of the authorization server can be used to obtain user information In [Login-free Configuration], the placeholder format used in your request parameters, return parameters, and URL must be:{AccessToken}
{AccessTokenType}	The token type obtained by calling the [ Get Token URL ] configured by the [code] callback of the authorization server . Currently, only thebearer type is supported. In [Login-free Configuration], the format of the placeholders used in your request parameters, return parameters, and URLs must be:{AccessTokenType}
{MatchPuDuAccount}	The user information is obtained through the token issued by your authorization service. The field where the user information you return matches the Purdue account. The placeholder must be: {MatchPuDuAccount}
{RedirectUri}	If your authorization server has validation for RedirectUri, please use it in your API request parameters for obtaining tokens or obtaining users. The placeholder must be: {RedirectUri}

parameter	Request method	URL parameter template description	Request parameter template description	Return parameter template description	Parameter Description
Client ID	Not involved	Not involved	Not involved	Not involved	Generated by the enterprise
Client Secret	Not involved	Not involved	Not involved	Not involved	Generated by the enterprise
Authorization server URL	Not involved	Not involved	Not involved	Not involved	This address can be used to learn about the relevant documents of the company's own OAuth2 service
Get the Token URL	GET	Call this interface via GET when sending an HTTP request thatthe original request ishttps://xxxxx.com/oauth/token?client_id=bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc&client_secret =d34cce4ca0b9116340451c2000a9af216d5b209579c7567b63347b38d6100b81&code= a0b9116340 Then the placeholder is: https://xxxxx.com/oauth/token?client_id= {ClientId} & client_secret = { ClientSecret} & code={Code}	Not involved	If your interface returns the following parameter: { "access_token": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc", "refresh_token": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc", "token_type": "bearer" } The template to be filled in is: { "access_token": "{AccessToken} ", "refresh_token": "{refreshTokenType} ", "token_type": "{AccessTokenType} " }	1. The interface only supports two HTTP request methods: GET and POST 2. If there are other fixed ones written directly in it, the request will expire when requested. 3. POST parameters support BODY RAW request method 4. The request header automatically carries:Content-Type: application/json 5. Make sure that the returned parameters can obtain user information through the token, otherwise you will not be able to log in normally
Get the Token URL	POST	Call this interface via POST when sending an HTTP request Assume that the original request interface is: https://xxxxx.com/oauth/token?client_id=bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc&client_secret=d34cce4ca0b9116340451c2000a9af216d5b209579c7567b63347b38d6100b81&code= a0b9116340 Then the placeholder is: https://xxxxx.com/oauth/token?client_id={ClientId} & client_secret = { ClientSecret} & code= {Code}	If your interface request parameters are: { "client_id ": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc", "client_secret ": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc" } The template to be filled in is: { "client_id ": " { ClientId } ", "client_secret ": " { ClientSecret } " }	If your interface returns the following parameter: { "access_token": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc", "refresh_token": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc", "token_type": "bearer" } The template to be filled in is: { "access_token": "{AccessToken} ", "refresh_token": "{refreshTokenType} ", "token_type": "{AccessTokenType} " }
Get user information URL	GET	Call this interface via GET when sending an HTTP request Assume that the original request interface is : https://xxxxx.com/api/v5/user?access_token=bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc Then the placeholder is: https://xxxxx.com/api/v5/user?access_token= {AccessToken}	Not involved	If your interface returns the following parameter: { "user_id":"xxxxxxxxx", "email":"xxxx@xx.com", "name": "xxxxxxxxx" } The template to be filled in is: { "user_id":"xxxxxxxxx", "email":"{MatchPuDuAccount}", "name": "xxxxxxxxx" }	1. The interface only supports two HTTP request methods: GET and POST 2. If there are other fixed ones written directly in it, the request will expire when requested. 3. POST parameters support BODY RAW request method 4. The request header automatically carries:Content-Type: application/json 5. Please make sure that the matching fields in the returned parameters match the Purdue login account, otherwise the login will fail. 6. When calling the user information interface, the HTTP Header will automatically include the Authorization: {AccessToken} or Authorization:Bearer {AccessToken} key-value pair
Get user information URL	POST	Call this interface via GET when sending an HTTP request Assume that the original request interface is : https://xxxxx.com/api/v5/user?access_token=bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc Then the placeholder is: https://xxxxx.com/api/v5/user?access_token= {AccessToken}	If your interface request parameters are: { "access_token": "bfe175c3180480253a228827c1c8a9393906d3808ccaea778e3dc70ebd2057fc" } The template to be filled in is: { "access_token": "{AccessToken} " }	If your interface returns the following parameter: { "user_id":"xxxxxxxxx", "email":"xxxx@xx.com", "name": "xxxxxxxxx" } The template to be filled in is: { "user_id":"xxxxxxxxx", "email":"{MatchPuDuAccount}", "name": "xxxxxxxxx" }
Account Matching Field	Not involved	Not involved	Not involved		The user information obtained by calling the [ Get User Information URL ] interface matches the Purdue login account field
Redirect address	Not involved	Not involved	Not involved		The redirection address jumps to the enterprise's authorization server to achieve the login-free function. After filling in the above configuration information, it is automatically generated.

4. Configuration process description (taking GITHUB as an example)

The first step is to register a github third-party application.
Homepage URL: fill in as you like
Callback URL: [Purdue Certification Service Address]/v1/redirect
the second step is to generate a Client in the created github application. secrets
be sure to keep your Client secrets, don't divulge.

After obtaining the Client ID and Client secret, go to the next step
step 3: Find the corresponding Purdue business platform for configuration
This is an example of the Purdue agent platform.

The Client ID & Client Secret has been obtained through the application of github. Next, follow Authenticating to the REST API with an OAuth app to make the relevant configuration.

Authorization Server URL:

that is, the authorization address of the Github authorization server. https://github.com/login/oauth/authorize

if your application needs to bring more parameters, you can configure them here.

Get the Token:

the interface of access_token is obtained by using the code (authorization code) called back by the authorization server.

By configuring the request parameters and returning data, through placeholders (refer to the above 【 placeholder Description ])

descript

Get user information:

you can use the access_token and token_type obtained through the preceding API to obtain user information. After obtaining the user information, it will return the data you configured through {MatchPuDuAccount} placeholder to match the account number field in the Purdue account number.

- Note that currently only the token_type of the bearers is supported. If it is not passed, it will be passed in the header by default. Pass the Authorization value.

descript

After the configuration is completed and saved successfully. A jump address will be generated below.

Shaped: [Purdue Certification Service Address]/v1/jump/【 Client ID ]]

HTTPS://LOGIN-CXG-TEST-INTEMALPUDU.WORK/V1JUMP/LV23LITOU6E04YUBRZVG

jump Address

descript

if you need to jump to a specified address, you can specify the jump by adding the redirect_uri parameter to the jump address (note that this parameter needs to be encoded).

5. Common errors

If an error message appears during use and the prefix of the message is the error code, the possible error causes are as follows:

Error Code	Possible Causes of Errors
3133	the user matching field is filled in. The interface for obtaining user information on your authorization server does not return the modified field or the returned field is null.
3134	please check whether your authorization server has returned authorization code normally
3135	error in obtaining your authorization configuration information, please check whether your login-free configuration is correct.
3137	the token url for obtaining your Authorization Service or the url for obtaining user information is incorrect, please check whether your login-free configuration is correct.
3138	parsing your get token url error, please check whether your get token url placeholder is used correctly.
3139	an error occurred in calling your url to obtain the token. Please check whether your url is correctly filled in, your url request parameters are correct, and your url request parameter placeholder is used correctly. If your authorization server has mandatory verification of [redirect_uri], please check whether your callback address in your authorization server is correctly filled in
3140	when calling your url to obtain the token, an error occurred when parsing the return parameter. Please check whether the placeholder for your return parameter is correct.
3141	An error occurred in calling your url for obtaining user information. Check whether your url is correctly filled in and whether your url request parameters are correct.
3142	you authorize the user information returned by the server. After the matching fields are obtained, the account status of the Purdue system is abnormal. Please log in to the Purdue system to modify the current account status.
3144	the user information you returned did not match the Purdue system account after obtaining the matching field.