Recieing (400) Bad Request When using Bearer Token Auth

Questions OAuth/OIDC
1

I have created a scrip to retrieve an Access_token successfully. When I try to use the Token in a simple API request I receive (400) Bad Request. I am new to OAuth in Okta and not sure what is wrong. Below is more info

Token Grant Responce
token_type expires_in access_token

Bearer 86400 eyJraWQiOiJ0WHhjRklJd3FfRXB (Truncated for sample)

Header Creation

$headers = New-Object “System.Collections.Generic.Dictionary[[String],[String]]”
$headers.Add(“Authorization”, “Bearer $token”)

Rest Call
$uri = “https://My Devinstance.okta.com/api/v1/users?limit=25”
$userList = Invoke-RestMethod -Uri $uri -Method Get -Headers $headers

Responce

Invoke-RestMethod : The remote server returned an error: (400) Bad Request.

Any help would be appreciated.

Thanks

2

Hello,

The token being passed should be fine as it didn’t have a 401 or 403 response. Since this is a 400 response, it could indicate an issue with the headers being passed. I was able to get a 400 response on my org’s /users endpoint if the Content-Type or Accept header was set to a value other than application/json, such as text/plain.

Are you seeing this issue if you include a content-type and accept header with the value application/json?
Additionally, is the function that is making the GET call injecting any additional headers or content?

1 Like
3

Thank you poul-okta tha at least got the get to respond. After changing the header, I made the call and am now receiving a 403 Forbiden. I have made sure that the grant types are applied and I "Think the Scope is correct. Here is my ltest header creation.

$headers = @{
“Accept” = “application/json”
“Content-Type” = “application/x-www-form-urlencoded”
“Authorization” = “Bearer $token”
“cache-control” = “no-cache”
}

4

Thanks for making that change, the headers should work properly. The 403 would mean that the proper authorization server is being used but it is missing a scope. For the GET call to the api/v1/users endpoint, it requires the okta.users.read scope. This will have to be granted on the Okta Application as well as in the /authorize call being made. You can determine if this is on the JWT itself by using https://jwt.io to decode the token and confirm this scope is listed in the scp claim.

1 Like
5

I have Decoded the Token and it Looks right. I am not sure exactly whay I am looking for. Below are the resuklts with a few Credential characters changed. What could be causing this.

{
“ver”: 1,
“jti”: “AT.KZy3oRB4oDu4hHnZ6uI6QkiR8MF3ClAisEh1pbg”,
“iss”: “https://dev-86659676.okta.com/oauth2/default”,
“aud”: “api://default”,
“iat”: 1695220344,
“exp”: 1695306744,
“cid”: “0oab9qgml0t41Xf6I5d7”,
“scp”: [
“test”
],
“sub”: “0oab9qgml0t41Xf6I5d7”,
“test”: “0oab9qgml0t41Xf6I5d7”
}

Outlook-signature_.png

Outlook-signature_.png

6

Thanks for providing the token, there are a couple issues that would be causing the 403 error.

For the issuer (iss) claim, I’m seeing that this is being authenticated with the custom authorization server, however in order to use the Okta APIs, this does require using the org authorization server. The issuer for the org authorization server is https://dev-86659676.okta.com. The endpoints for this authorization server can be found on the well-known endpoint at

https://dev-86659676.okta.com/.well-known/openid-configuration

Documentation regarding the two different types of authorization servers can be found at Authorization servers | Okta Developer

Additionally, the scope needs to be okta.users.read. This is the scope that is required when making GET calls to the api/v1/users endpoint. This should be included in the /authorize request as well as granted within the application. When viewing the application in Okta, the Okta API scopes can be found on the Okta API Scopes tab. From here you can view which scopes are granted or not granted. By granting them, this means that when authenticating with the application, that scope is able to be included in the request.

1 Like