Custom domains require developers to configure their own OAuth login provider credentials (by registering an OAuth app/client within those providers' configuration) that take the form of a client ID and client secret. These credentials will be used for two purposes:
To facilitate a Rollup login through the Custom domain so that the redirect URI (return_uri parameter in the standard) can point to the custom domain.
To provide a custom user experience where the branding within the authorization screen of the upstream OAuth provider is the custom one the developers expect, and not the Rollup one we provide by default.
The configuration screen should require both, client ID and client secret to be provided by the user. It should also display the redirect URI user should be setting in the upstream OAuth provider. This will be of the format https://(custom domain)/connect/(provider)
This ticket tracks:
[x] UX design in Console for the configuration screens
[ ] Implementation of UX in codebase
[ ] Implementation of GET and POST endpoints as well as data model in Starbase DO
picassobanana
commented
1 year ago 
Custom domains require developers to configure their own OAuth login provider credentials (by registering an OAuth app/client within those providers' configuration) that take the form of a client ID and client secret. These credentials will be used for two purposes:
return_uriparameter in the standard) can point to the custom domain.The configuration screen should require both, client ID and client secret to be provided by the user. It should also display the redirect URI user should be setting in the upstream OAuth provider. This will be of the format
https://(custom domain)/connect/(provider)This ticket tracks: