Support fetching access token as a public client in OAuth 2.0 UX

[JasonYeMSFT]

The current behavior of Insomnia for Authorization Code flow makes it hard to use the OAuth 2.0 UX to fetch access tokens for a public client.

In the OAuth 2.0 UI, there is a "client secret" and a "Credentials" field indicating how to send the client secrets. Public clients don't have client secrets. While I can leave the "client secret" field empty, Insomnia seems to assume that the client must have a secret and breaks the flow to get an access token.

Observations:

1. If I leave the "client secret" field empty and select advanced "Credentials" option to use authorization header, the token request made by Insomnia will still include a basic authorization header whose value is <my_client_id>:, indicating that the client secret is an empty string, rather than considering the client as a client without a secret.
2. The body of the token request doesn't have the "client_id" field. When I tested this flow with MS Entra platform, this would cause the server to reject the request with 400 because in OAuth 2.0 spec, client id is required in the token request if the client hasn't been authenticated with the authroziation server, which will always be the case for public clients.

client_id
REQUIRED, if the client is not authenticating with the
authorization server as described in Section 3.2.1.

After discovering these, I can clone the token request sent by Insomina, manually add the client_id field to the body and replay the request to successfully get an access token.

I think it's good for Insomnia to support OAuth 2.0 flows for public clients to help users test such scenarios.

[JasonYeMSFT]

A little more background on why it is good to have the Authorization Code flow support public clients when it seems like implicit_grant flow can be used. Microsoft Entra platform discourages using implicit_grant flow. There are configurations that in the application registration that lets the authorization server reject requests attempting to use the implicit_grant flow. This would be a blocker for users who want to use Insomnia to work with such applications. https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-implicit-grant-flow#security-concerns-with-implicit-grant-flow

[poojithap11]

Hi,

Thank you for sharing the details.

I tested the public OAuth client scenario you reported using insomnia latest version 12.4, and was able to successfully fetch the access token without providing a client secret.

Could you try the same flow using the insomnia v12.4 and confirm if it is working now as expected?

Thank you.