PUT /api/v1/authorizationServers/{authServerId}

Replaces an authorization server

Servers

https://{yourOktaDomain}

Path parameters

Name	Type	Required	Description
`authServerId`	String	Yes	`id` of the Authorization Server

Request headers

Name	Type	Required	Description
`Content-Type`	String	Yes	The media type of the request body. Default value: "application/json"

Request body fields

Name	Type	Required	Description
`id`	String	No	The ID of the custom authorization server
`audiences[]`	Array	No	The recipients that the tokens are intended for. This becomes the `aud` claim in an access token. Okta currently supports only one audience.
`created`	String	No
`issuerMode`	String	No	Indicates which value is specified in the issuer of the tokens that a custom authorization server returns: the Okta org domain URL or a custom domain URL. `issuerMode` is visible if you have a custom URL domain configured or the Dynamic Issuer Mode feature enabled. If you have a custom URL domain configured, you can set a custom domain URL in a custom authorization server, and this property is returned in the appropriate responses. When set to `ORG_URL`, then in responses, `issuer` is the Okta org domain URL: `https://${yourOktaDomain}`. When set to `CUSTOM_URL`, then in responses, `issuer` is the custom domain URL configured in the administration user interface. When set to `DYNAMIC`, then in responses, `issuer` is the custom domain URL if the OAuth 2.0 request was sent to the custom domain, or is the Okta org's domain URL if the OAuth 2.0 request was sent to the original Okta org domain. After you configure a custom URL domain, all new custom authorization servers use `CUSTOM_URL` by default. If the Dynamic Issuer Mode feature is enabled, then all new custom authorization servers use `DYNAMIC` by default. All existing custom authorization servers continue to use the original value until they're changed using the Admin Console or the API. This way, existing integrations with the client and resource server continue to work after the feature is enabled.
`name`	String	No	The name of the custom authorization server
`description`	String	No	The description of the custom authorization server
`credentials`	Object	No
`credentials.signing`	Object	No
`credentials.signing.nextRotation`	String	No	The timestamp when the authorization server changes the Key for signing tokens. This is only returned when `rotationMode` is set to `AUTO`.
`credentials.signing.lastRotated`	String	No	The timestamp when the authorization server started using the `kid` for signing tokens
`credentials.signing.kid`	String	No	The ID of the JSON Web Key used for signing tokens issued by the authorization server
`credentials.signing.rotationMode`	String	No	The Key rotation mode for the authorization server Possible values: `"AUTO"` `"MANUAL"`
`credentials.signing.use`	String	No	How the key is used Possible values: `"sig"`
`issuer`	String	No	The complete URL for the custom authorization server. This becomes the `iss` claim in an access token.
`status`	String	No	Possible values: `"ACTIVE"` `"INACTIVE"`
`lastUpdated`	String	No

How to start integrating

Add HTTP Task to your workflow definition.
Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
Click Test request to test run your request to the API and see the API's response.