PUT /api/v1/authorizationServers/{authServerId}

Replaces an authorization server

Servers

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
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

Valid values:

  • "AUTO"
  • "MANUAL"
credentials.signing.use String No

How the key is used

Valid values:

  • "sig"
status String No

Valid values:

  • "ACTIVE"
  • "INACTIVE"
jwks_uri String No

URL string that references a JSON Web Key Set for encrypting JWTs minted by the custom authorization server

lastUpdated String No
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

issuer String No

The complete URL for the custom authorization server. This becomes the iss claim in an access token.

jwks Object No

A JSON Web Key Set for encrypting JWTs minted by the custom authorization server

jwks.keys[] Array No
jwks.keys[].n String No

The modulus of the RSA key

jwks.keys[].kty String No

The type of public key

Valid values:

  • "RSA"
jwks.keys[].e String No

The key exponent of a RSA key

jwks.keys[].kid String No

The unique identifier of the key

jwks.keys[].status String No

The status of the public key

Valid values:

  • "ACTIVE"
  • "INACTIVE"
jwks.keys[].use String No

The intended use of the public key

Valid values:

  • "enc"
accessTokenEncryptedResponseAlgorithm String No

The algorithm for encrypting access tokens issued by this authorization server. If this is requested, the response is signed, and then encrypted. The result is a nested JWT. The default, if omitted, is that no encryption is performed.

Valid values:

  • "RSA-OAEP-512"
  • "RSA-OAEP-384"
  • "RSA-OAEP-256"

How to start integrating

  1. Add HTTP Task to your workflow definition.
  2. 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.
  3. Click Test request to test run your request to the API and see the API's response.