I'm trying to understand OAuth and Securing APIs better when using External Identity Providers, and all my research on it doesn't really seem to apply to my issue, so I'm starting to wonder if I'm approaching what I'm doing completely wrong at this point.

I have a SPA that is an item manager for a game, it has a custom API (this is also mine) that it gets all of it's data from, such as the items from the game, and saved setups, etc. Users can login to the SPA using their Discord account, which let's them save their setups against their account so they can retrieve them later, among other minor features, that's the main thing.

As the website can be used without login, I was allowing the API to be accessed without any authentication, then adding authentication to it when the user has logged in to give elevated permissions on the API.

My current login flow is:

  1. App performs an Implicit Grant to Discord
  2. Discord Access token returned to App
  3. Discord Access Token is passed to API as a Password Grant, with username discord (I'm sure this is a very bad way to do this, but this is the main reason I'm making this post)
  4. API returns Access Token for accessing the rest of the API

While my current system works, I'm sure it's not the best way to do it, and as I've had requests to make the API open to others to use, I want to make sure this part is all squared off and working well first.

Would appreciate any help anyone can give with organising this mess

  • Do you have any particular design goals that are not being met? Are you looking for the base design for how to make those three things work together without step 3?
    – Turtle
    Jul 19, 2021 at 14:58
  • @Turtle Yes, I think so. I'm struggling to understand how to work with an external identity provider and have that associate to an account on my side, and what method to use to authenticate the user. Step 3 was the only way I could work out to allow me to take that auth token from Discord and convert it into an auth token for my API.
    – Ihm
    Jul 19, 2021 at 15:20

1 Answer 1


Since you're using the implicit grant, the SPA gets the token from Discord and then you have to send it to your (API) server to exchange it for your own access token. There is nothing really wrong with exchanging one token for another one, security wise. It's not really a password grant if you're not sending the user's password. If this fits your needs, you can leave it as it is.

For completeness, I should mention that the implicit flow has some vulnerabilities. To mitigate those, you might consider migrating to the authorization code flow with PKCE, which is for the same use case, but more secure.

If you'd like to streamline things, here are some suggestions.

Accept Discord tokens directly

The simplest approach would be to accept the Discord access token in your API directly instead of issuing your own. Depending on your language and framework, you would intercept the access token on every request, validate it and perform business logic, then return your application user data for the controllers/routes to consume. Basically what you currently do when you get the Discord token, except on every request that needs it. To get the user data back to the SPA, you can expose an endpoint like /user/self that returns any necessary data.

With this approach, your clients can use any of the flows offered by Discord without the token exchange step.

Issue your own tokens

When you need to issue your own tokens, the approach to forwarding authentication to an external provider is typically to use a flow where your server ends up with the access token at the end of it. This can be the authorization code flow or implicit flow with form post. They key is that the server has the tokens at the end of the flow, and can perform business logic before invoking its own authorization mechanism of choice.

You should be able to find tutorials for this for your stack, and maybe even a ready-made Discord client library if you're using a popular language.

Going down this route, you have much more control. But by issuing your own tokens, you're taking on the role of authorization server. So if you need to support additional sign-in flows, like the client credentials flow (for automated sign-ins) then you would need to implement that too.

  • I should have mentioned it in my original post, but I was considering the possibility of adding more identity providers, such as Google or Twitch have been requested, so I think I would be leaning towards issuing my own tokens. I'm just unsure exactly how to do that outside of the method I've used (Making a Password Grant call to hand over the the Discord token to my API.
    – Ihm
    Jul 24, 2021 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.