Description
Up until now, we have basically aligned ourselves to a subset of the parameters of OAuth & Open ID Connect log in flows. This is the right move as it is the way to truly paint a broad stroke for authentication.
However, there comes a time when auth providers like to diverge from the spec or have more features than the spec... and GitHub is deciding to do that.
We need a way to allow Core (for now and extensions later if we want) to send provider specific information to the auth provider so that it can do what it wants with that.
The specific case is that GitHub will enable the ability to sign in with Google... and we'd like to show a button in product to do so and fast track to the Google sign in page instead of just the normal GitHub sign in page.
In doing research (see below), I found it's pretty split in real world examples... in other words, it's not in the spec how to do this, and there isn't a standard. Because of this, I didn't want to lock in to a specific pattern and instead wanted to provide a way to let providers extend at their leisure.
With that in mind, the following API addition:
declare module 'vscode' {
export interface AuthenticationProviderSessionOptions {
/**
* Allows the authentication provider to take in additional parameters.
* It is up to the provider to define what these parameters are and handle them.
* This is useful for passing in additional information that is specific to the provider
* and not part of the standard authentication flow.
*/
[key: string]: any;
}
// TODO: Implement this interface if needed via an extension
// export interface AuthenticationGetSessionOptions {
// /**
// * Allows the authentication provider to take in additional parameters.
// * It is up to the provider to define what these parameters are and handle them.
// * This is useful for passing in additional information that is specific to the provider
// * and not part of the standard authentication flow.
// */
// [key: string]: any;
// }
}Although, we may want to put this one level down to allow for more top level props.
Research of a few providers:
domain
Auth0
- Uses domain in their hosted login pages and some SDKs
- Format:
https://{tenant}.auth0.com/authorize?domain=company.com - Used for Home Realm Discovery (HRD) to route users to their enterprise connection
Custom Enterprise Solutions
- Many enterprise identity gateways use domain for email domain-based routing
- Common pattern: extract domain from email and route to appropriate identity provider
provider
Firebase Auth
- Uses provider parameter in their authentication flows
- Examples: provider=google.com, provider=microsoft.com, provider=github.com
Supabase Auth
- Uses provider query parameter for third-party authentication
- Format:
/auth/v1/authorize?provider=github
Custom Multi-Provider Solutions
- Many homegrown solutions use provider to specify which OAuth provider to use
- Common values: google, microsoft, github, facebook, twitter
Clerk
- Uses provider in their authentication URLs
- Format: /oauth/authorize?provider=oauth_google
organization
WorkOS
- Uses organization parameter for enterprise SSO
- Format: /sso/authorize?organization=org_123456
- Maps organizations to their configured identity providers
Okta
- Uses org or organization in some contexts for multi-org routing
- Format: https://{org}.okta.com/oauth2/authorize
Custom B2B SaaS Solutions
- Many B2B applications use organization to route users to their org's identity provider
- Common in multi-tenant enterprise applications
tenant
Microsoft Entra ID
- Uses tenant in the URL path (not query parameter)
- Format: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
- tenant can be tenant ID, domain name, or "common"/"organizations"/"consumers"
Auth0
- Uses tenant in the subdomain rather than as a parameter
- Format: https://{tenant}.auth0.com/authorize