Is it possible to create a request in an Insomnia workspace that fetches access and ID tokens from an OAuth2 authorization server as though Insomnia is a public client, i.e. unlike a confidential client, it doesn't have access to the client secret? It seems as though Insomnia won't send the client ID to the token endpoint as one of the query parameters. The call to the authorize endpoint works fine, as I get a pop-up browser window where I can login to the Okta authorization server and see that it succeeds, but after that Insomnia tells me "Failed to fetch token" and the Response Timeline shows:
> POST /oauth2/default/v1/token HTTP/2
> Host: dev-[redacted].okta.com
> user-agent: insomnia/2022.6.0
> content-type: application/x-www-form-urlencoded
> accept: application/x-www-form-urlencoded, application/json
> authorization: Basic [redacted, but is base-64 encoded "<client-id>:"]
> content-length: 242
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
| grant_type=authorization_code&code=[redacted]&redirect_uri=[redacted]&state=any+random+string&code_verifier=[redacted]
* We are completely uploaded and fine
< HTTP/2 401
[skipping]
| {"error":"invalid_client","error_description":"Client authentication failed. Either the client or the client credentials are invalid."}
Per RFC 6749: In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id".
but I don't see a client_id in the query string above. I do see the client ID encoded in the Authorization header, but if I understand correctly that syntax would be used only if it's a confidential client with access to the client secret, in which case the secret would follow the colon before encoding.
I'm using Insomnia 2022.6.0 as it's the latest version that sends code_challenge_method as "S256". Later versions appear to send it as "SHA-256" which my authorization server doesn't understand (and which appears to not comply with RFC 7636).