simov / grant

OAuth Proxy
MIT License
4.08k stars 257 forks source link

Discord Profile route always 401 Unauthorized #277

Closed SunburntRock89 closed 2 years ago

SunburntRock89 commented 2 years ago
app
...
    .register(grant.fastify({
        defaults: {
            origin: config.webServer.url,
            transport: "session",
            prefix: "/login",
            response: ["profile"],
        },
        discord: {
            client_id: auth.discord.ID,
            client_secret: auth.discord.secret,
            scope: ["identify"],
            callback: "/dashboard",
        }
    })
...

In grant/lib/profile.js, logging options:

{
  method: 'GET',
  url: 'https://discord.com/api/users/@me',
  headers: { authorization: 'Bearer undefined' }
}

The authorization header defined line 31 options.headers.authorization = `Bearer ${output.access_token} output.access_token is always undefined, at least when using Discord.

If you enable the raw response, output.raw.access_token does exist.

simov commented 2 years ago

That's weird, access_token is literally taken from what you can see as raw, which seems to have it. I will have to test it on my end.

simov commented 2 years ago

I was just about to say that it works on my end, can you try adding tokens in:

response: ["tokens", "profile"],
SunburntRock89 commented 2 years ago

I was just about to say that it works on my end, can you try adding tokens in:

response: ["tokens", "profile"],

Yep, that fixed it, thanks!

simov commented 2 years ago

That seems like a bug to me though, I will have to take a look.

SunburntRock89 commented 2 years ago

As far as I read into it, output is just whatever is going to be given to the transport (ie saved in session).

So if you've got the tokens response, there'll be access_token in the response, but if you don't, output.access_token is undef and so you end up with grant sending the header:

authorization: Bearer undefined
simov commented 2 years ago

That's true, but having just the profile as response option seems like a valid use case to me. It's just that I am not forwarding the token there.

SunburntRock89 commented 2 years ago

Fair enough