OAuth2 Client Credentials Grant: 400 Bad Request - "assertion type is not supported"

Support
1

**SHello OpenEMR Community,

We are trying to obtain an OAuth2 access token using the client credentials grant type to interact with the OpenEMR API. We are sending a POST request to the standard token endpoint (/oauth2/default/token).

Here’s how we are constructing the request:

  • Method: POST
  • URL: [Your OpenEMR Base URL]/oauth2/default/token
  • Headers:
    • Authorization: Basic [Base64-encoded client_id:client_secret]
    • Content-Type: application/x-www-form-urlencoded
  • Body (form-urlencoded):
    • grant_type=client_credentials

We are intentionally not including the client_id, client_secret, or scope parameters in the request body, as we are using Basic Authentication in the header, which should cover the client credentials part according to standard OAuth2 practices for this grant type.

However, we are receiving a 400 Bad Request response from the server with the following JSON body:

{
  "error": "invalid_request",
  "error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.",
  "hint": "assertion type is not supported",
  "message": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."
}

We are particularly confused by the hint: "assertion type is not supported". We are not using any JWT assertions or similar mechanisms, just the standard client credentials grant with Basic Auth.

Could anyone shed light on why we might be getting this specific error with this setup? Does OpenEMR’s OAuth2 implementation perhaps require parameters differently even when using Basic Auth for client credentials, or could there be a specific server configuration we need to be aware of?

Any help or pointers would be greatly appreciated!

Thanks,
[Your Name/Username]ituation**
Describe your problem here

OpenEMR Version
I’m using OpenEMR version

Browser:
I’m using:

Operating System
I’m using:

Search
Did you search the forum for similar questions?

Logs
Did you check the logs?
Was there anything pertinent in them?
Please paste them here (surround with three backticks (```) for readability.
You can also turn on User Debugging under Administration->Globals->Logging User Debugging Options=>All

2

The error you’re encountering seems to be a result of the OpenEMR OAuth2 implementation expecting additional parameters, even though you are using Basic Authentication in the header. Based on the error message and the specific hint “assertion type is not supported,” it’s likely that OpenEMR’s OAuth2 configuration or endpoint requires specific parameters that you’re missing in the request body, even when using Basic Auth for client credentials.

Here’s how to resolve the error and correctly structure your request:

  1. Ensure Client Credentials are Sent in the Correct Place

Even though you are sending the client_id and client_secret in the Authorization header via Basic Authentication, OpenEMR might expect those credentials to be explicitly passed in the request body too, particularly if it doesn’t correctly handle Basic Auth in your setup.

You need to include the following parameters in the form body:

client_id (your OpenEMR client ID)

client_secret (your OpenEMR client secret)

grant_type (set to client_credentials)

Here’s the updated request structure:

Request Structure:

Method: POST

URL: [Your OpenEMR Base URL]/oauth2/default/token

Headers:

Authorization: Basic [Base64-encoded client_id:client_secret]

Content-Type: application/x-www-form-urlencoded

Body (application/x-www-form-urlencoded):

grant_type=client_credentials

client_id=[Your Client ID]

client_secret=[Your Client Secret]

Even though you are already including the credentials in the Authorization header, OpenEMR might still require them to be included in the body for this grant type. This is common in some implementations.

  1. Double-Check Scope Requirement

Some OAuth2 implementations require the scope parameter to be included, even for client credentials. If OpenEMR is expecting a scope parameter, include it in your request body.

For example:

scope=your_required_scope (Optional, only if required by your OpenEMR OAuth2 configuration)

  1. Verify OpenEMR’s OAuth2 Configuration

It’s possible that OpenEMR has specific configurations or restrictions in its OAuth2 setup that are not fully aligned with the general OAuth2 flow you’re expecting. The error hint mentioning “assertion type is not supported” could be a sign that OpenEMR’s OAuth2 implementation expects some specific configuration related to how the client credentials are handled.

To troubleshoot this further:

Review OpenEMR’s OAuth2 Settings: Check if there are any specific requirements around how client credentials are sent, or if any specific scope or additional parameters are required.

Look for Customizations in OpenEMR: If your OpenEMR instance has custom modifications, these could affect how OAuth2 requests are processed.

Example of Correct Request:

POST [Your OpenEMR Base URL]/oauth2/default/token

Headers:

Authorization: Basic [Base64-encoded client_id:client_secret]

Content-Type: application/x-www-form-urlencoded

Body:

grant_type=client_credentials

client_id=your_client_id

client_secret=your_client_secret

scope=your_required_scope (optional)

If after including the client_id and client_secret in the body the error persists, review the OpenEMR documentation or any OAuth2-related configuration in the server to ensure it’s aligned with the OAuth2 client credentials grant type.

Try this…

3

@Qiaben this is a ton of information that is completely wrong. I’m going to have to start flagging your posts if you can’t stop posting invalid information. If you event attempted to follow your examples you would find that they don’t work.

Client Credentials Grant is currently configured to only support the private_key_jwt for the token_endpoint_auth_methods_supported. The grant type only allows access to the BULK on FHIR system scopes for export so if you are trying to use it for server to server write communication it won’t work for you there.

I do think we might have a bug in our .well-known properties file suggesting client_secret_post is a valid authentication for that grant type which its not.

4

“We apologize for the confusion and will ensure to provide clear and accurate information moving forward.”