Draft: Org/Project Auth Tokens

[stephanie-anderson]

Background

The reason why we talk about another way to issue auth tokens is, that we want to improve the experience of uploading source maps as much as possible. Improving the way an SDK authenticates, will also improve the overall experience of setting up source map uploads for our users (and maintaining that setup in the time that follows).

User-based Auth Tokens

Currently, we invite users to issue a user-based auth token. This has some negative side effects, as the token may not work anymore (and therefore the entire reporting to Sentry) when that user leaves the organization.

Screenshot of one of our SDK documentations:

Organization-based Auth Tokens

There is also the option to create an Internal Integration - which as the name suggests, leaves many users wondering if this is the right way to setup organization-based (or project-based) authentication/authorisation. Also, integrations weren't initially thought to fulfil this purpose. Issuing organization-based auth tokens is also only possible with a certain level of user account privileges. In a bigger organization with several development teams and projects, relying on an Owner or Manager of the org may not result in a frictionless user experience.

Pros/Cons of existing options

User-based auth tokens

• ✅ all users can issue it
• ❓ check: other users of that organization / team can not view it
• ❓ check: other users of that organization / team can not revoke it
• ❌ will stop working, once the user ceases to exist

Org-based auth tokens

• ❌ only Owner and Manager users can issue it
• ❓ check: only Owner and Manager users can view it
• ❓ check: only Owner and Manager users can revoke it
• ✅ will continue to work, independent of specific users within that organization

Open questions

• can we reuse internal integrations, but make it more accessible (permission) and easier to understand (wording)?
• display the token also after creating it? Armin: No, security team asks not to show it afterwards, just create a new token
• What kind of privileges should the token have? Should we introduce new scopes?
• Take inspiration from Github (new token system)
• AWS machine tokens
• tokens will have a prefix, so we can scan for it (if it was accidentially commited to version control)
• make sure there is only one token per CI system, tokens should not be too specific, so that they can be reused across projects (it should alter also handle codecov uploads)

What do we need (what, why, who, until when)

Build a new token system with JWT, any person in the org has permissions to create that kind of token

Who: Alex, Francesco & Riccardo
When: starting on June 1st

Build the user interface changes (view, manage)

Who: Jesse, Ale, Steven (requirements & design), Francesco (UI implementation)
When: Ale & Steven can start on May 31st, Jesse will be there for feedback

Create a helper for generating a token out of docs.sentry.io

Who: Luca
When:

Add token generation to @sentry/wizard?

Who: Luca
When:

Org- instead of user-based tokens for source maps upload

Why:
Who:
When:

Encode "org" and "target" (?) information into the token

Why:
Who:
When:

Other notes

docs.sentry.io

We want to offer an easy way to issue new auth tokens, when reading through a Getting Started SDK tutorial.

wizard in sentry.io

There should also be a way to start (or continue) setting up source maps when you're logged in in sentry.io. This helper should also offer to issue an auth token.

Org based auth tokens

New screen for an overview of already issued auth tokens

• reuses the business logic of internal integrations, but removes all useless UI elements

- should we still show it as an internal integration afterwards? - navigation changes (remove user based auth tokens, add org based auth tokens) - what about permissions for creating internal integrations?

New screen to create a new issue

See also

• Simplified Upload Tokens for CI Usage rfcs#91
• #proj-auth-token in Slack

[stephanie-anderson]

Closing due to new epic issue