You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the user can login with Google and a Local User/Password (as well as Facebook in a temporary branch but this was mostly a proof of the recently proposed schema design in #6716).
Goal
We want to identify and prioritize alternative universal "Login with [Service]" buttons (pop-up based) to expand our single sign-on (SSO) options.
For example, platforms like Overleaf support ORCID and IEEE accounts to target academic users, while developer platforms heavily utilize GitHub or GitLab.
Scope & Technical Requirements
Protocol: Ideally supports standard OAuth 2.0 or OpenID Connect (OIDC).
(We can support other options, but it would require a bit more leg work to set up.)
Payload Requirements: The provider must expose endpoints to reliably retrieve:
A verified primary email address
The user's name
A permanent, unique user ID (sub claim)
Out of Scope (For Now):
Custom Enterprise, University, or Workplace SSO (SAML, Shibboleth, or tenant-specific Okta/Azure AD setups)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Context
Currently the user can login with Google and a Local User/Password (as well as Facebook in a temporary branch but this was mostly a proof of the recently proposed schema design in #6716).
Goal
We want to identify and prioritize alternative universal "Login with [Service]" buttons (pop-up based) to expand our single sign-on (SSO) options.
For example, platforms like Overleaf support ORCID and IEEE accounts to target academic users, while developer platforms heavily utilize GitHub or GitLab.
Scope & Technical Requirements
Protocol: Ideally supports standard OAuth 2.0 or OpenID Connect (OIDC).
(We can support other options, but it would require a bit more leg work to set up.)
Payload Requirements: The provider must expose endpoints to reliably retrieve:
Out of Scope (For Now):
Custom Enterprise, University, or Workplace SSO (SAML, Shibboleth, or tenant-specific Okta/Azure AD setups)
Questions for the team
What services make good potential options?
All reactions