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
We want the key login support for this application to be ORCID SSO, so there are no custom accounts, only ORCID logins.
Your idea
Supabase supports SSO for any SAML 2.0 protocol compatible providers. They support Google Workspaces, Okta, Auth0, various Microsoft provides by default:
Support is disabled by default, but available for Pro plans, which means $25/month. They have a nice glossary on the page to learn key concepts. There are a variety of pieces of metadata we would need to share with ORCID to enable this and a bunch of information we need from ORCID to make this work. There are instructions on the link above about how to configure it, and then a super simple client-side API for initiating a sign in.
Supabase Auth requires SAML assertions that provide an email address. ORCID does not always provide one.
Buuuut, that doesn't matter, because ORCID only supports OAuth, not SAML. ORCID has many different types of OAuth support. The only kind we would need for this platform is "3-legged (authorization code) scopes" which give us the ability to read public information on the record. We could also use it's "implicit OAuth" support to get a the ORCID iD and an access token that allows reading from the ORCID API to get public information, without a server, since we only need read access. Here is a tutorial on how:
Unfortunately, while Supabase supports many OAuth providers with integrations to its auth system, there is not yet support for custom OAuth providers. There are rumors that they may add support this Fall, but no promises, and there have been rumors before.
An alternative is to rely on Auth0 for authentication, as it does support custom OAuth providers. Auth0 does integrate with Supabase, though it is fairly involved, and would impose more costs ($35/month).
If none of that is viable, we can always use vanilla Supabase magic link emails, and do OAuth separately, in order to pull information from ORCID. This would be a less seamless experience for researchers, since they would have to log in twice. Another alternative yet is to just not integrate with ORCID at all, and just gather everything within our app, rather than relying on ORCID as a ground truth for contact info, expertise, etc.
The text was updated successfully, but these errors were encountered:
The problem
We want the key login support for this application to be ORCID SSO, so there are no custom accounts, only ORCID logins.
Your idea
Supabase supports SSO for any SAML 2.0 protocol compatible providers. They support Google Workspaces, Okta, Auth0, various Microsoft provides by default:
https://supabase.com/docs/guides/auth/enterprise-sso/auth-sso-saml
Support is disabled by default, but available for Pro plans, which means $25/month. They have a nice glossary on the page to learn key concepts. There are a variety of pieces of metadata we would need to share with ORCID to enable this and a bunch of information we need from ORCID to make this work. There are instructions on the link above about how to configure it, and then a super simple client-side API for initiating a sign in.
Supabase Auth requires SAML assertions that provide an email address. ORCID does not always provide one.
Buuuut, that doesn't matter, because ORCID only supports OAuth, not SAML. ORCID has many different types of OAuth support. The only kind we would need for this platform is "3-legged (authorization code) scopes" which give us the ability to read public information on the record. We could also use it's "implicit OAuth" support to get a the ORCID iD and an access token that allows reading from the ORCID API to get public information, without a server, since we only need read access. Here is a tutorial on how:
https://info.orcid.org/documentation/api-tutorials/api-tutorial-get-and-authenticated-orcid-id/
There's even a simple JavaScript widget that implements this sign in process:
https://github.com/ORCID/orcid-auth-widget
Unfortunately, while Supabase supports many OAuth providers with integrations to its auth system, there is not yet support for custom OAuth providers. There are rumors that they may add support this Fall, but no promises, and there have been rumors before.
An alternative is to rely on Auth0 for authentication, as it does support custom OAuth providers. Auth0 does integrate with Supabase, though it is fairly involved, and would impose more costs ($35/month).
If none of that is viable, we can always use vanilla Supabase magic link emails, and do OAuth separately, in order to pull information from ORCID. This would be a less seamless experience for researchers, since they would have to log in twice. Another alternative yet is to just not integrate with ORCID at all, and just gather everything within our app, rather than relying on ORCID as a ground truth for contact info, expertise, etc.
The text was updated successfully, but these errors were encountered: