Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: allow api token middleware to fetch from db (#6344)
## About the changes When edge is configured to automatically generate tokens, it requires the token to be present in all unleash instances. It's behind a flag which enables us to turn it on on a case by case scenario. The risk of this implementation is that we'd be adding load to the database in the middleware that evaluates tokens (which are present in mostly all our API calls. We only query when the token is missing but because the /client and /frontend endpoints which will be the affected ones are high throughput, we want to be extra careful to avoid DDoSing ourselves ## Alternatives: One alternative would be that we merge the two endpoints into one. Currently, Edge does the following: If the token is not valid, it tries to create a token using a service account token and /api/admin/create-token endpoint. Then it uses the token generated (which is returned from the prior endpoint) to query /api/frontend. What if we could call /api/frontend with the same service account we use to create the token? It may sound risky but if the same application holding the service account token with permission to create a token, can call /api/frontend via the generated token, shouldn't it be able to call the endpoint directly? The purpose of the token is authentication and authorization. With the two tokens we are authenticating the same app with 2 different authorization scopes, but because it's the same app we are authenticating, can't we just use one token and assume that the app has both scopes? If the service account already has permissions to create a token and then use that token for further actions, allowing it to directly call /api/frontend does not necessarily introduce new security risks. The only risk is allowing the app to generate new tokens. Which leads to the third alternative: should we just remove this option from edge?
- Loading branch information
1 parent
b738a2a
commit 70499dc
Showing
7 changed files
with
101 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters