Proposal for /v2/tokeninfo

[darthmaim]

This PR adds a simple /v2/tokeninfo endpoint that returns information about the API key.

// GET /v2/tokeninfo
// Authorization: Bearer api-key
{
    "name"   : "API key for super awesome app",
    "scopes" : ["account", "characters", "guilds"]
}

The name of the API key is useful for displaying it in the apps settings, so the users knows which key the app is using.

The scopes array is just a simple list of all granted scopes.

[lye]

Ah, the name field is a good idea. My current implementation just provides

{
    "permissions" : ["account", "characters", "guilds"]
}

I'll see if I can get the name in there too. I also put it at /v2/tokeninfo since it's got more than just the permissions, but that's basically bikeshedding.

Was hoping to deploy this endpoint sometime this week, but it's already Wednesday 😢

[darthmaim]

I also put it at /v2/tokeninfo

I updated the PR.

"permissions"

Do you want it called "permissions" or "scopes". I just called it scopes from the good old OAuth2 days.

[sliekens]

Just deploy it on Friday at 5pm, it's probably fine

[lye]

Do you want it called "permissions" or "scopes". I just called it scopes from the good old OAuth2 days.

I'd prefer permissions; I think the term is more user-accessible.

Just deploy it on Friday at 5pm, it's probably fine

I can't be that guy all the time. Shooting for next week.

[darthmaim]

Sounds good to me.

[msmolev]

How about changing it slightly to make API keys be somewhat a bit more resilient to evil actors trying to re-use stolen tokens? For that API Key + tokeninfo should:

• provide time of creation
• allow "customization" of the token with extra destination/application field

This would allow applications to be a bit more certain about the owner of the keys.
When user is asked for API Key, time of "ask" gets recorded, and keys earlier than that timestamp would be rejected. Same for the non-matching destination/application. This means that if someone steals my API key for "App1" and tries to present it to "App2", the second app would refuse to work with it.

The reason for application / destination field versus "Name" user gives the token is that user might provide something sensitive there under impression that name is private. So "Application" could be useful.

API Key creation time probably can be exposed as-is :)

If the problem of presenting someone else's key is not that critical, please disregard this comment

[darthmaim]

This is now live 👍

@lye I added the "id" property to this PR, could you merge this now, so we can use it to track future changes of this endpoint? (Also, should I create a separate PR to add all already existing endpoints to make future PRs to them easier?)

[tivac]

@darthmaim if you want to I'm ok w/ that, though I think doing it on-demand sounds like the easier path going forward.

[darthmaim]

But having all the endpoints already defined in the repository makes it easier to spot the changes made in a PR. I think I will just make the PR to add all existing endpoints and we can discuss it there if you want.

Thanks for merging :)

[lye]

Ah yeah, thanks for taking care of that guys.

I added the id field in on a whim (technically the entire key is immutable, but the id is distinct and also immutable) when I was looking to expose key creation date -- which apparently we don't currently track. Completely forgot to make a note of the change in the PR.