Sample success responses for pre-issue access token action¶
In this section, you'll find examples of success responses for various scenarios involving access token modifications. These samples demonstrate how to structure your responses based on different types of operations, ensuring that your external service interacts correctly with WSO2 Identity Server during the pre-issue access token action.
Adding a custom claim to the access token¶
To add a custom claim to the access token, use the /accessToken/claims/ path in the event.accessToken request. This path includes an array of claims.
When adding a new claim, you need to specify the index where the claim should be inserted. The specified index must not be greater than the number of elements currently in the array. If you want to add the claim to the end of the array, you can use the - character as the index.
Only string, integer, boolean, and string type arrays are allowed to be added to the access token claims.
Refer to the example response below, which demonstrates adding a custom claim to the last position of access token claims:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "add",
"path": "/accessToken/claims/-",
"value": {
"name": "customSID",
"value": "12345"
}
}
]
}
Refer to the example response below, which demonstrates adding an multi valued array type custom claim to the last position of access token claims:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "add",
"path": "/accessToken/claims/-",
"value": {
"name": "customArray",
"value": [
"foo",
"bar"
]
}
}
]
}
Changing the access token validity period¶
The duration for which the token is valid can be changed in seconds. Refer to the example response below, which demonstrates changing the validity period of the access token:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "replace",
"path": "/accessToken/claims/expires_in",
"value": 300
}
]
}
Modifying audience values¶
When adding, replacing or removing an audience value, you need to specify the index where the audience is added, replaced or removed. The specified index must not be greater than the number of elements currently in the array. If you want to add, replace or remove the audience to the end of the array, you can use the - character as the index.
Refer to the example response below, which demonstrates modifying an audience value:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "replace",
"path": "/accessToken/claims/aud/-",
"value": "example.com"
},
{
"op": "add",
"path": "/accessToken/claims/aud/-",
"value": "https://example.com/resource"
},
{
"op": "remove",
"path": "/accessToken/claims/aud/0"
}
]
}
Modifying scope values¶
When adding, replacing or removing scopes, you need to specify the index where the scope is added, replaced or removed. The specified index must not be greater than the number of elements currently in the array. If you want to add, replace or remove the scope to the end of the array, you can use the - character as the index.
Refer to the example response below, which demonstrates modifying scopes:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "add",
"path": "/accessToken/scopes/-",
"value": "custom-scope-1"
},
{
"op": "remove",
"path": "/accessToken/scopes/-"
},
{
"op": "replace",
"path": "/accessToken/scopes/0",
"value": "edit"
}
]
}
Modifying an additional OIDC claim in the access token¶
You can replace or remove additional OIDC claims in the access token. When replacing or removing multi valued claims of array type you need to specify the index of the value that is replaced or removed. The specified index must not be greater than the number of elements currently in the array.
Refer to the example response below, which demonstrates modifying OIDC claims:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "remove",
"path": "/accessToken/claims/groups/0"
},
{
"op": "replace",
"path": "/accessToken/claims/groups/1",
"value": "partner"
},
{
"op": "replace",
"path": "/accessToken/claims/given_name",
"value": "alice"
}
]
}
Changing the refresh token validity period¶
The duration for which the refresh token is valid can be changed in seconds. Refer to the example response below, which demonstrates changing the validity period of the refresh token:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "replace",
"path": "/refreshToken/claims/expires_in",
"value": 48600
}
]
}
Adding a custom parameter to the token endpoint response¶
To add a custom top-level parameter to the token endpoint response, use the /response/parameters/- path in the event.response request.
String, integer, boolean, JSON objects, and arrays are allowed as parameter values. The parameter name must not collide with a standard parameter name, such as access_token, scope, expires_in, token_type, refresh_token, id_token, or an already added custom parameter.
Note
Unlike token endpoint response parameters, access token and refresh token claims only accept string, integer, boolean, and string type array values. JSON objects, and arrays containing anything other than strings, aren't allowed as claim values, so they can't be injected into the access token or the refresh token.
Refer to the example response below, which demonstrates adding a custom parameter to the token endpoint response:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "add",
"path": "/response/parameters/-",
"value": {
"name": "custom_param",
"value": "custom_value"
}
}
]
}
Refer to the example response below, which demonstrates adding a custom parameter with a nested JSON object value to the token endpoint response:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
"actionStatus": "SUCCESS",
"operations": [
{
"op": "add",
"path": "/response/parameters/-",
"value": {
"name": "custom_object",
"value": {
"context": {
"a": "b"
},
"nested": {}
}
}
}
]
}
Removing an optional parameter from the token endpoint response¶
You can suppress optional standard parameters, such as refresh_token or id_token, from the token endpoint response. To do this, use the /response/parameters/ path followed by the name of the parameter you want to remove, in the event.response request. Standard parameters that are always present in the response, such as access_token, scope, expires_in, and token_type, can't be removed.
Refer to the example response below, which demonstrates suppressing the refresh token from the token endpoint response: