From 7aedff2dbc4f41b20cc8464d1d57c8a4fb1c5436 Mon Sep 17 00:00:00 2001 From: mdtro Date: Mon, 23 Jan 2023 18:21:04 -0600 Subject: [PATCH 1/5] initial draft for org option to disallow user api tokens --- text/XXXX-org-user-token-restriction.md | 42 +++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 text/XXXX-org-user-token-restriction.md diff --git a/text/XXXX-org-user-token-restriction.md b/text/XXXX-org-user-token-restriction.md new file mode 100644 index 00000000..7de9739c --- /dev/null +++ b/text/XXXX-org-user-token-restriction.md @@ -0,0 +1,42 @@ +- Start Date: 2023-01-18 +- RFC Type: feature +- RFC PR: - +- RFC Status: `draft` + +# Summary + +Provide an option to organization owners to disallow all user interaction with their organization that is using a user API token for authentication. + +# Motivation + +Sentry treats users and organizations as two separate entities. A user can be a part of multiple organizations. + +An organization may have stricter requirements or a lower risk appetite compared to a user. We provide options for organizations to require SSO and 2FA to be enabled on a user account that wishes to interact with their organization. However, a user can authenticate with a personal API token, which inherently does not require controls like a 2FA prompt. + +As a result, protecting the user API token lies solely on the user. Leaking secrets in source control, personal computers infected with malware, or vendor breaches can lead to these tokens being compromised, exposing an organization to increased risk in Sentry. + +If a personal user API token is leaked, an organization owner does not have the ability to revoke the token and must coordinate with the user to do so -- further increasing the time an organization is potentially exposed. + +# Solution + +1. Add a toggle in the Organization Settings to deny use of personal API tokens for authentication against their organization. +2. Update authentication middleware to check for the targeted organization's preference. + +# Drawbacks + +- An organization upon enabling this may find some of their automation or integrations broken. + +# Supporting Data + +Secret or API token leaks are commonplace: + +- [CircleCI's recent breach (Jan 2023)](https://circleci.com/blog/jan-4-2023-incident-report/) +- [Heroku and TravisCI token leaks](https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/) + +# Related Work + +- [Improved API Tokens](https://github.com/getsentry/rfcs/pull/32) + +# Potential Future Work + +- Allow organizations to require an SSO flow to authorize a user token before use. From 75cc2c931d9a56ef3a8d8c9bf385c59ba0b76542 Mon Sep 17 00:00:00 2001 From: mdtro Date: Mon, 23 Jan 2023 18:25:10 -0600 Subject: [PATCH 2/5] rename file to match PR number --- ...er-token-restriction.md => 0068-org-user-token-restriction.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{XXXX-org-user-token-restriction.md => 0068-org-user-token-restriction.md} (100%) diff --git a/text/XXXX-org-user-token-restriction.md b/text/0068-org-user-token-restriction.md similarity index 100% rename from text/XXXX-org-user-token-restriction.md rename to text/0068-org-user-token-restriction.md From 805274bc93d49ebd57c8e73c1cb9ed29ce7ba59b Mon Sep 17 00:00:00 2001 From: mdtro Date: Thu, 9 Mar 2023 11:29:05 -0600 Subject: [PATCH 3/5] simplified rfc --- text/0068-org-user-token-restriction.md | 57 ++++++++++++++++++++----- 1 file changed, 47 insertions(+), 10 deletions(-) diff --git a/text/0068-org-user-token-restriction.md b/text/0068-org-user-token-restriction.md index 7de9739c..ab3d762c 100644 --- a/text/0068-org-user-token-restriction.md +++ b/text/0068-org-user-token-restriction.md @@ -5,26 +5,61 @@ # Summary -Provide an option to organization owners to disallow all user interaction with their organization that is using a user API token for authentication. +Provide an option to organization owners to disallow all user interaction with +their organization that is using a user API token for authentication. # Motivation -Sentry treats users and organizations as two separate entities. A user can be a part of multiple organizations. +Sentry treats users and organizations as two separate entities. +A user can be a part of multiple organizations. -An organization may have stricter requirements or a lower risk appetite compared to a user. We provide options for organizations to require SSO and 2FA to be enabled on a user account that wishes to interact with their organization. However, a user can authenticate with a personal API token, which inherently does not require controls like a 2FA prompt. +An organization may have stricter requirements or a lower risk appetite +compared to a user. We provide options for organizations to require SSO and 2FA +to be enabled on a user account that wishes to interact with their organization. +However, a user can authenticate with a user API token, which inherently +does not require controls like a 2FA prompt. -As a result, protecting the user API token lies solely on the user. Leaking secrets in source control, personal computers infected with malware, or vendor breaches can lead to these tokens being compromised, exposing an organization to increased risk in Sentry. +As a result, protecting the user API token lies solely on the user. -If a personal user API token is leaked, an organization owner does not have the ability to revoke the token and must coordinate with the user to do so -- further increasing the time an organization is potentially exposed. +Leaking secrets in source control, personal computers infected with malware, or +vendor breaches can lead to these tokens being compromised and exposes +an organization to increased risk. -# Solution +If a user API token is leaked, an organization owner has two options: -1. Add a toggle in the Organization Settings to deny use of personal API tokens for authentication against their organization. -2. Update authentication middleware to check for the targeted organization's preference. +1. Coordinate with the user to rotate their API token. +2. Remove the user from their organization. -# Drawbacks +An organization owner **cannot** delete another user's API token. -- An organization upon enabling this may find some of their automation or integrations broken. +This also assumes the organization owner is made aware of the leaked token. +Currently, notification would only go to the user who owns the token. + +# Proposed Solution + +Owners should have more control on how user API tokens +interact with their organization. + +In the majority of cases organization owners have requested the ability +to disallow interaction with their organization via a user API +token completely. These organizations typically follow our recommended +practice of using a custom integration for automation tasks. + +**I'm proposing we add a toggle option under the organization settings +to disallow usage of user API tokens for authentication to their organization.** + +## Pros + +- Solves the concern for the majority of customers who are concerned about + user API tokens +- Relatively simple implementation + +## Cons + +- Organization owners do not have a way to determine if + their users are using personal API tokens +- An organization upon enabling this may find some of their automation + or integrations broken # Supporting Data @@ -40,3 +75,5 @@ Secret or API token leaks are commonplace: # Potential Future Work - Allow organizations to require an SSO flow to authorize a user token before use. +- Instead of a simple on/off toggle, we could create a more complex _policy_ system + allowing user API tokens to be used for certain scopes within an org From f5e3ddbe8c56bf3e9e815688d743bf74598bcc19 Mon Sep 17 00:00:00 2001 From: mdtro Date: Thu, 9 Mar 2023 11:39:48 -0600 Subject: [PATCH 4/5] added note about a future policy system to measure token age --- text/0068-org-user-token-restriction.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0068-org-user-token-restriction.md b/text/0068-org-user-token-restriction.md index ab3d762c..128366ca 100644 --- a/text/0068-org-user-token-restriction.md +++ b/text/0068-org-user-token-restriction.md @@ -76,4 +76,5 @@ Secret or API token leaks are commonplace: - Allow organizations to require an SSO flow to authorize a user token before use. - Instead of a simple on/off toggle, we could create a more complex _policy_ system - allowing user API tokens to be used for certain scopes within an org + allowing user API tokens to be used for certain scopes within an org, meet + required maximum lifetimes, etc. From a16869ecac7d481f704643ec239a09bfd6ea59c5 Mon Sep 17 00:00:00 2001 From: mdtro <20070360+mdtro@users.noreply.github.com> Date: Wed, 31 Jan 2024 16:31:27 -0600 Subject: [PATCH 5/5] add unanswered question about api application tokens --- text/0068-org-user-token-restriction.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/0068-org-user-token-restriction.md b/text/0068-org-user-token-restriction.md index 128366ca..2b0dd42a 100644 --- a/text/0068-org-user-token-restriction.md +++ b/text/0068-org-user-token-restriction.md @@ -78,3 +78,9 @@ Secret or API token leaks are commonplace: - Instead of a simple on/off toggle, we could create a more complex _policy_ system allowing user API tokens to be used for certain scopes within an org, meet required maximum lifetimes, etc. + +# Unanswered Questions + +- How do we account for API application tokens? + - Should they still be allowed? + - What about those that are created in the backend by using integrations?