Troubleshooting oauth token exchange on cloud
# support
a
We use clerk.dev for auth, and have configured an oauth application within clerk to do a token exchange with medplum. Things appear to pass through clerk appropriately, and wind up back at api.medplum.com/auth/external?code=...&state=... but medplum responds with an OperationOutcome listing
Failed to verify code - check your identity provider configuration
. I'm trying to diagnostically see what/why Medplum is erroring but there are no OperationOutcome records showing within my project. The
auth/external
URL includes a state JSON parameter that lists the correct projectID/clientID/bunch-of-other-stuff. Does Medplum cloud expose other details? Do I need to selfhost medplum to watch the authentication flow? Just trying to find the natural troubleshooting flow as I work through these issues.
r
Hi @altintx - yes unfortunately this flow is a bit hard to debug. For security reasons, we're not allowed to share additional details in the returned error
This erorr typically means that clerk returned an error to our server. Running on localhost and catching the log would beone way to debug
a
Thank you. Stepping through with the code you referenced it looks like the other side doesn't support token exchanges.
r
Hi @altintx , do you mind sharing the error message you received from clerk? In our experience, sometimes there are some settings around how to configure PKCE that cause issues
a
Copy code
{
  "error": "unsupported_grant_type",
  "error_description": "The authorization grant type is not supported by the authorization server"
}
We tried every permutation of PKCE based on earlier support threads seen here, but it's token exchange of any kind. They've said that they're looking into it.
r
Got it. Well thanks for putting the work into debugging. Please let me know if they come to a resolution. We'd love to support Clerk
r
It's possible there is an issue on the Clerk side... some community members have run into issues in the past https://discord.com/channels/905144809105260605/905144809105260608/1120432274761072834
a
Clerk support gave me a definitive "we don't support this" today. I'm going to explore the deprecated alternate authorization method, and barring that, see about some kind of bridge on my side
r
Thanks for circling back @altintx !
159 Views