Can't get token from SSO - Grant type authorization_code is not supported

Hello there friends,

So i’m working on a tool and i need to gather assets and jobs from my character.

I’m following docs/sso/web_based_sso_flow.html

I was able to get the code from /v2/oauth/authorize/ and have it properly stored.

Now i’m just trying to get the token with it and i keep receiving authorization_code is an invalid grant type which makes no sense.

I searched the forums and tried changing a lot of stuff. The Content-Type header and the body formating and nothing seems to work

I’m using Laravel( PHP ) and Guzzle to develop my solution.

When i use guzzle debugging the request goes like this:

POST /v2/oauth/token HTTP/1.1 Host: login. eveonline .com Accept: application/json Authorization: Basic PROPERLY_ENCODED_CLIENT_SECRET User-Agent: GuzzleHttp/7 Content-Type: application/x-www-form-urlencoded Content-Length: 57 * upload completely sent off: 57 out of 57 bytes * old SSL session ID is stale, removing * Mark bundle as not supporting multiuse

My request is quite simple with the authorization header already being calculated and added on the instantiation.

The authorization seems to be working because if remove the authorization header it gives me 401 instead of 400.

I’ve also used postman to test this but get the same problem.
The curl reads as:
curl --request POST ‘https:// login. eveonline .com/v2/oauth/token’
–header ‘Authorization: Basic PROPERLY_ENCODED_CLIENT_SECRET’
–header ‘Host:
–header ‘Content-Type: application/x-www-form-urlencoded’
–header ‘Cookie: __cf_bm=vw.YOARQUa2yX8X7ZfaNUrp9x63e8Ct5GXXEfUDwS30-1643808566-0-AUsQXPwBxhYUusb7reYq6vfwlq0KTo8aOwnKmbmWRZ0Uu1tylhgFFbp/+uZjeGW4Iq/4RgIFh5wvI1777IM9BcWt3Jh7H+9CH1yM2tiWgM12; lang=en’
–data-urlencode ‘grant_type=authorization_code’
–data-urlencode ‘code=SECRET_CODE’

So the error seems to be definitely on the body but what am i doing wrong?

Had to split some URL’s there because apparently im a new user.
Please account for that if you copy the curl request.

I see that you have data-urlencode twice. Without knowing how postman works, I’d suggest moving that into one line.

Your PHP code looks fine though, so that’s probably not the issue.

Here’s the code I’m using (ES6, TS). The only difference I see is the Accept header.

await``, `grant_type=authorization_code&code=${code}`, {
            headers: {
                Authorization: `Basic ${Buffer.from(`${esiKey}:${esiSecret}`).toString('base64')}`,
                'Content-Type': 'application/x-www-form-urlencoded',
                Host: '',
                Accept: 'application/json',

Added the accept header and nothing changed.
Same error.

Also tried the manually using curl on the terminal with one data-urlencode.

Also tried both again with a new code without success.

@Rihan_Shazih could you post a working CURL for me? With obfuscated data of course.

Can you share how you’re getting your authorization code? Like are you sure you’re not doing the implicit flow and getting a token instead of the authorization code?

I’m following this doc.

Everything happens fine until the actual /token interaction.

Is there anything you want to know specifically?

It don’t seem like i received a JWT token.

This is an sample


code: lKg1BH6lv0A2uKYgNtTcCT

state: c444a767-c8af-4f23-a5cd-49e3d0ca3c77

He shared that above. The call to /token will yield and authorization token and a refresh token.

@Akida_Ohaya Just to be sure, can you show us your code when you also pass the Authorization header? Feel free to redact it, just want to be sure that it’s set up correctly. I don’t see it in the picture of getAuthorizationToken yet.

The header is set on the constructor. I use a very simple wrapper on guzzle to add basic config and logging.

The Guzzle debug output the header properly.

I have the base64 value preprocessed.
I did like CLIENT_ID:CLIENT_SECRET then saved on an env file.

That looks fine to me. The only problem I can think of is that there’s a problem with the Authorization header value. 401 sounds to me like eve can’t recognize who you are, indicating that it can’t map the header to a client id and secret that is in its database.

When you construct an Authorization header for CLIENT_ID_123 and SECRET_456, do you get Basic Q0xJRU5UX0lEXzEyMzpTRUNSRVRfNDU2? Sorry for being a nitpick here, just want to make sure that this is not the problem :slight_smile:

Im getting 400 for the /token issue.
Sorry if i wrote in a confusing way.
I was getting the authentication wrong before and getting 401 but i solved that and started receiving 400.
Well at least i thought i had solved it.

I ran the base64 on what you asked and got: Q0xJRU5UX0lEXzEyMzpTRUNSRVRfNDU2
Im using and getting the base64 URL one.

Ok so i redid the whole enchilada and discovered that even though the error changed from 401 to 400 the error was STILL inside the header.

I got a knack about how i was getting the error on postman, terminal curl and the application and started using php base64_encode instead of preprocessing the basic value header and voila.

Got 200 and a token.

So i guess the lesson here is triple check base64 generation and the form body if you are getting this.

Keep in mind that there’s more than one “base64” encoding variant, and PHP only implement one. You’d have to strtr() the results sometimes to massage it into working fashion.

@Tonto_Auri Could you provide a bit more information when that should happen?

I used the default function and PHP already does it URL safe. At least seems to be the encoding expected by Eve ESI.
I’m now able to properly query the token.

I couldn’t think of a situation where i need to do that.
To me either the encode does it and it is on the right encoding or i need to search another encoding function.

I’m not opposed to do one myself but this is very basic and widespread. There is a function for every RFC for sure already done.
Now re-parsing it after encoding seems a bit of both but i didn’t understand the use case.

Then that’s all you need. I wasnt’ so lucky in my past projects >.>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.