feat: OAuth 2.0 Provider (behind feature flag)

[jordanh]

Description

Implements the start of an OAuth 2.0 Provider, configurable from Org Admin and hidden behind a org-level feature flag (oauthProvider). Note: this is not intended to be a production-ready solution, rather, the a merge-ready solution that can be iterated upon and used for internal testing (or potentially, by self-hosted customers).

It provides the following:

• The oauthProvider feature flag
• An Org Admin interface for adding/removing application provider configurations
• OAuth 2.0 token issuance and authorization
• Two simple scopes graphql:query, graphql:mutation
• A yoga plugin for analyzing incoming ad-hoc queries against scopes

It does not implement:

• Any kind of query complexity or fine-grained scopes
• The .well-known route
• Force re-authentication when issuing a new token
• Refresh tokens

Demo

https://www.loom.com/share/e129366000ce4164a93c6d20cf6e0213

Testing scenarios

[Please list all the testing scenarios a reviewer has to check before approving the PR]

• Can list the feature flag

query {
  getAllFeatureFlags {
    description
    featureName
    scope
    expiresAt
  }
}

• Can migrate up

• Can migrate down

• Can migrate up again

• Verify that the Org Admin OAuth 2.0 interface is hidden without the feature flag set

• Can add the feature flag

mutation {
  applyFeatureFlag(flagName: "oauthProvider", subjects: {
    orgIds: ["AP9kDq76Ra"]
  }){
    __typename
    ... on ApplyFeatureFlagSuccess {
      organizations {
        name 
        featureFlag(featureName: "oauthProvider")
      }
      users {
        email
        featureFlag(featureName: "oauthProvider")
      }
      teams {
        name
        featureFlag(featureName: "oauthProvider")
      }
    }
    ... on ErrorPayload {
      error {
        message
      }
    }
  }
}

• See the OAuth Provider Interface after the flag is added

• Add a new OAuth 2.0 App

• Can save it

• Can edit it

• Can click regenerate, then cancel secret regeneration

• Can click regenerate, then confirm creating a new secret

• Can get a token

• Can use the token

Final checklist

• I checked the code review guidelines
• I have added Metrics Representative as reviewer(s) if my PR invovles metrics/data/analytics related changes
• I have performed a self-review of my code, the same way I'd do it for any other team member
• I have tested all cases I listed in the testing scenarios and I haven't found any issues or regressions
• Whenever I took a non-obvious choice I added a comment explaining why I did it this way
• PR title is human readable and could be used in changelog

[jordanh]

Ok @mattkrick , I've made another suite of changes – thanks again for looking this over

[Dschoordsch]

-2

We would never enable this feature flag for anybody other than us on SaaS production. Yes, we could use our su tokens, but better if we didn't.

Organization scope feature flags can be enabled by enterprise organizations on their own.

[jordanh]

@Dschoordsch to pick this up

addressed

[Dschoordsch]

Scopes don't work

[Dschoordsch]

I have tested it with a made up client and added some scope tests.
Tests should be a bit more comprehensive before we enable it for a 3rd party.