Thank you Erick; modifying the role solved our predicament. It would have been nice had the error stated a bit more than just "invalid_login_attempt".

Erick... The documentation you cite above, look at the table underneath "The Access Token Response". That response contains three fields: access_token, expires_in and token_type. The access_token is what is subsequently used. That access_token contains a base64 encoded jwt. I have no control over what fields are inside the…

If you try yourself, you'll see that inside "access_token", you will find a base64 encoded string that you can evaluate using jwt.io. It will look something like this: { "sub": "1009;41", // Not sure what this is, but assumes it is connected to the OAuth 2.0 Client Credentials Setup setup "aud": [ "<The integration…

JSON Response field named "access_token" is the access token. Hence the name "access_token". ;)

We compared both flows and the tokens used. One of those tokens is the access token that was returned after I posted my client_assertion to the token endpoint. The second token was the token we received when we tested the Authorization Code Grant Flow. We wanted to compare these tokens to see if it would provide some clues…

Login Audit Trail reports e-mail, company name, ip and 'success'. Integration record: m2m setup: authorized apps: role: Client credentials flow { "sub": "1009;41", // Not sure what this is, but assumes it is connected to the OAuth 2.0 Client Credentials Setup setup "aud": [ "<The integration application id>;<account id>",…

POST yields the same result. 401.

On a related note: On Saturday I used my client_assertion to acquire an access_token. Today I reran that exact same query. I expected an error saying my client_assertion had expired, but it happily returned an access_token.