Malformed authorization_details claim

Using okta.myAccount.manage scope on client credentials flow against a custom authorization server produces an authorization_details claim in the access token that is not documented and is non-compliant with RFC 9396 section 2.

The JWT payload is returning an array of strings, when it should be an array of objects.

Create JWT:
oauth2c ${OKTA_URL} \
--client-id ${OKTA_CLIENT_ID} \
--client-secret ${OKTA_CLIENT_SECRET} \
--grant-type client_credentials \
--auth-method client_secret_basic \
--response-mode query \
--response-types code \
--scopes okta.myAccount.manage \
--pkce \
--no-browser

JWT payload:
{
"ver": 1,
"jti": "AT.zq1ynGL4xxxxxxxxx-AVxnfCClMUgZB1uU_4Q34",
"iss": "``https://foo.oktapreview.com/oauth2/default``",
"aud": "api://default",
"iat": 1790288257,
"exp": 1790291857,
"cid": "abc123",
"scp": [
"okta.myAccount.manage"
],
"sub": "abc123",
"authorization_details": [
"okta.myAccount.manage"
]
}

It looks like this is the case for all okta.* scopes. Here’s another example:
oauth2c ${OKTA_URL} \
--client-id ${OKTA_CLIENT_ID} \
--client-secret ${OKTA_CLIENT_SECRET} \
--grant-type client_credentials \
--auth-method client_secret_basic \
--response-mode query \
--response-types code \
--scopes okta.myAccount.email.read \
--scopes okta.myAccount.profile.read \
--pkce \
--no-browser

JWT payload:
{
"ver": 1,
"jti": "AT.gEFm5Qy40xxxxxxBLYeJ72I4G71PsKGkXY9eWNg",
"iss": "https://foo.oktapreview.com/oauth2/default",
"aud": "api://default",
"iat": 1790355121,
"exp": 1790358721,
"cid": "abc123",
"scp": [
"okta.myAccount.email.read",
"okta.myAccount.profile.read"
],
"sub": "abc123",
"authorization_details": [
"okta.myAccount.email.read",
"okta.myAccount.profile.read"
]
}

Hi,
Could you provide the sample cURL call for the token call you are using? I am not able to see the authorization_detail claim in the token I get from the CC flow.

curl -s -X POST "${DEFAULT_OKTA_ISSUER_URL}/v1/token"
-u "${CC_OKTA_CLIENT_ID}:${CC_OKTA_CLIENT_SECRET}"
-H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=client_credentials&scope=okta.myAccount.manage"

Could you also provide your Okta domain against which you are testing the CC flow?

Im checking to see if that’s something I can share in a public forum like this. I can tell you the domain is under *.oktapreview.com

And I incorrectly stated in my initial post that this is happening with a customer auth server. It’s actually only happening with the default auth server.