Right now the system only supports one OAuth Provider. This should be handled similar to DATABASES in Django and allow for multiple identity providers accessible at their own child endpoints.
Then, logic should be written by the end user in their username resolution function to handle the different identity providers, or allow it to be chucked into one universal handler.
Eventually we could get Modals involved, but that could pose a potential security risk so we'll stick to static entries.
Potentially offer our own user modal with a section for Identity Provider.
+1 Love this idea, but would also like to see this implemented via Webfinger so only an email address is required before the Oidc client can query the OIDC settings for the domain.
Right now the system only supports one OAuth Provider. This should be handled similar to DATABASES in Django and allow for multiple identity providers accessible at their own child endpoints.
Then, logic should be written by the end user in their username resolution function to handle the different identity providers, or allow it to be chucked into one universal handler.
Eventually we could get Modals involved, but that could pose a potential security risk so we'll stick to static entries.
Potentially offer our own user modal with a section for Identity Provider.