I’m working on integrating Miro’s OAuth flow into my application and running into issues during the token exchange step. I can successfully get users through the authorization process and receive the authorization code back from Miro. However, when I try to exchange this code for an access token using a POST request to their token endpoint, I keep getting a 401 unauthorized error response.
I’ve double checked my client ID, client secret, and redirect URI multiple times. The authorization code appears to be valid since it was just returned from Miro’s authorization server. I’m making the request with the proper Content-Type header and including all the required parameters like grant_type, code, client_id, client_secret, and redirect_uri.
Has anyone else encountered this issue with Miro’s OAuth implementation? What could be causing the 401 error during the token exchange step even with correct credentials?
make sure ur auth code isn’t expired yet - they typically last around 10 mins. also, don’t reuse the same code, they are single-use. had the same issue before and it was from testing with an old code.
I encountered this exact problem last month and it turned out to be related to my request headers. The Miro API can be picky about how you structure the POST request. Make sure you’re sending the parameters in the request body as form data rather than JSON, and verify that your Content-Type header is set to ‘application/x-www-form-urlencoded’. I was initially sending JSON data which worked fine for other OAuth providers but Miro specifically expects form-encoded data. Also worth checking if there are any special characters in your client secret that might need URL encoding when included in the form data.
Check if you’re encoding the client credentials correctly in your request. Some implementations require the client_id and client_secret to be base64 encoded in the Authorization header rather than passed as form parameters. Also verify that your redirect_uri matches exactly what you registered in the Miro app settings - even trailing slashes can cause issues. I had a similar problem where the redirect_uri I was sending in the token request had a slightly different format than what was used during the initial authorization step. The URIs need to be identical across both requests.