For requesting a new access token, as per the example available here, you will need to pass client id and client secret in the authorization header in the format of "Authorization: Basic " + base64_encode(client_id + “:” + client_secret) or in the body of the POST request.
Body
grant_type=refresh_token&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=offline_access+openid&refresh_token={refresh_token}&client_id={client_id}&client_secret={client_secret}
Response:
{
“error”: “invalid_request”,
“error_description”: “The grant was issued for another authorization server.”
}
The error here is that the refresh token was issued through a different authorization server and can not be used on the “default” custom authorization server.
Depending on the case, if you have “/oauth2/”, then you will need to change the request path and modify “default” to what is written there. If it simply returns “org.okta.com”, then you will need to use the Okta authorization server with the path /oauth2/v1/token.
I decoded the access_token and it shows the issuer as “{org}.okta.com”. I tried the POST request again with the following URL: https://{org}.okta.com/oauth2/v1/token – but I’m receiving the following:
{
“error”: “invalid_client”,
“error_description”: “Client authentication failed. Either the client or the client credentials are invalid.”
}
In my authorization header, should I be using “Basic {accessToken}” or “Bearer {accessToken}”?
If you are testing this through Postman, please add the client ID and client secret under Authorization >> Type >> Basic Auth. For username, please add the value for client ID and, for password, the value for client secret.
The error you are shown tells me you are making this request to https://oktaDomain/oauth2/v1/token, which is the token endpoint for the Org Authorization server, and will only work if you are looking to get OAuth tokens to use against Okta APIs, as described here. That guide tells you how to create a service app with private_key_jwt auth instead of a client secret to use at the Org Authorization server.
If you are instead trying to get tokens to use against your own server, you must use a Custom Authorization Server, which typically requires having the API Access Management license available for your org. You can tell if you have this option by logging into the admin console and navigating to Security → API → Authorization Servers.
If you have this drop-down option listed, you will see a list of the existing custom authorization servers available for your org. If this is your use case and you see these servers, you will need to 1) create a custom scope that your machine-to-machine application can request and 2) update your /token call to use one of these servers as the issuer and ensure you are requesting this additional scope.
For example, instead of calling https://oktaDomain/oauth2/v1/token, you can instead call https://oktaDomain/oauth2/default/v1/token if you have the “default” authorization server available, which is created for you in your org when the API Access Management feature is enabled.
