Issue with POST /token

Questions OAuth/OIDC
1

I am making a POST request in POSTMAN with the following

URL: https://{oktaDomain}/oauth2/default/v1/token

Body:

  • grant_type: refresh_token
  • redirect_uri: {localhost}
  • scope: openid offline_access
  • refresh_token: {refresh_token}

Headers:

  • Accept: application/json
  • Authorization: Bearer {accessToken}
  • Content-Type: application/x-www-form-urlencoded

I am receiving the following error:

{
“error”: “invalid_client”,
“error_description”: “No client credentials found.”
}

Do I need to pass in a client_id and client_secret? Any help is appreciated, thank you

2

Hi @jayrc

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.

3

Hello @dragos,

This is what my request looks like (I’ve removed my client_id, client_secret, host, refresh_token for privacy reasons):

POST /oauth2/default/v1/token HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Cache-Control: no-cache

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.”
}

4

Hi @jayrc

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.

If the previous access/bearer token and refresh token were issued through the same authorization server, then you can use a tool like https://jsonwebtoken.io to decode the access token and see what is the issuer (it should look like “org.okta.com”, “org.okta.com/oauth2/default” or “org.okta.com/oauth2/”)

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.

5

Hello @dragos,

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}”?

6

Hi @jayrc

Please use Basic and a base 64 encoding of client id, column and client secret instead of access token. The algorithm looks like the following

Authorization: Basic " + base64_encode(client_id + “:” + client_secret)

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.

7

Hello @dragos,

That worked perfectly. Thank you for the help and quick responses, have a great day!

8

Hello @dragos,

I wanna test through Postman to get an acces token with client credentials flow, but it’s doesn’t work

I got in body urlencoded : grant_type : client_credentials, scope: goodone
headers : Accept : application/json

Authorization : like you said for Username : client_id and Password : Client_secret
and i got this error :o

image
image1288×596 70.3 KB

What i’m doing wrong ?
i don’t have to use “clientid:client_secret” encode as base64 for postman so ?

Thank you for your help !

9

What is your use case, @Neojet?

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.

1 Like