getsentry
Improved API Tokens
Improved API tokens to provide customers an easier means of detecting accidentally leaked secrets by integrating with Github's Secret Scanning Service and other static analysis tools.
a few questions:
- "Verify the legacy token is valid/invalid" - are you just checking if its expired or not?
- For legacy tokens, you are proposing to store it in a hashed format, and will you also have it prepended with the token type identifier?
- What backwards compatibility issues need to be considered for making changes to the frontend (ie. not displaying the token after the one time after it is created)?
@misha-sentry
"Verify the legacy token is valid/invalid" - are you just checking if its expired or not?
This would be our standard verification. For example, does the token exist and is it not expired?
For legacy tokens, you are proposing to store it in a hashed format, and will you also have it prepended with the token type identifier?
Only the hashed format. The plaintext token value that would contain the prefix would not exist in the database.
What backwards compatibility issues need to be considered for making changes to the frontend (ie. not displaying the token after the one time after it is created)?
We deploy frontend and backend separately. Deploying both at the same time is high risk since rollouts happen gradually. Instead, we'll have to figure out a path where they can each be deployed separately without breaking each other. I'll need to partner with the engineering teams to figure that one out.
@markstory this is largely unrelated to this RFC but I wonder if there would be some benefit to encoding the silo into the token. That way we could route based on the information in the token from the central silo. Since we are now talking about re-issuing tokens anyways we might take that opportunity.
I wonder if there would be some benefit to encoding the silo into the token. That way we could route based on the information in the token from the central silo.
The ApiToken models we currently have don't include any organization links which makes encoding a region into them hard as the tokens would work for any organization the user has access to.
