Security of anonymous sign-ins

[hf]

A common concern is that enabling anonymous sign-ins on your project decreases its security. This is not true, and hopefully this thread will help you grasp why.

Anonymous users are just users that don't have an email address or phone number associated yet. Otherwise, they are just like any other user in the system. They have their own row in auth.users, their own unique user ID, etc.

All RLS policies in place for regular users also apply to anonymous users. Therefore, the security of the project does not decrease. To further illustrate this, let's briefly forget that anonymous users exist.

Let's imagine a human trying to trick the project's Auth system, so they use a temp-mail service (like DuckDuckGo's duck.com or any of the multitude temp-mail services out there) to sign up. That user account has an email address, but it's not a particularly identifying one. You can't link it to a human, and in fact the email address may not exist 5 minutes later.

What I just described is the anonymous sign-ins feature, just implemented differently.

Therefore, if the project has a security issue before enabling anonymous sign-ins, they will continue to have the same security issue. If they don't have one, they will continue to not have one after enabling.

So what's the deal then? Anonymous sign-ins (like the temp-mail case above) can be slightly easier to abuse with bots and scripts than OAuth sign-in methods. For this reason turn on CAPTCHA which ensures to some degree of certainty that it's humans and not scripts behind the sign-ins.

Supabase Auth exposes the is_anonymous claim in the user's JWT if that user comes from a supabase.auth.signInAnonymously() call. This is mainly a restrictive feature. Let's look at some examples of how it can be used.

Suppose your project uses only Google and Apple sign-in, which to a high degree of certainty enforce "humanness." (You have to give up your address, real phone number, they track your phone etc.) But, you're faced with an adoption problem. Folks are not signing up because they want to try out the product first without giving their user data.

One way to solve this is to add "demo mode" in your project. This will allow users to try out the real product without committing their personal data or money ahead. But this poses an issue for you -- you don't want "spam" on your platform, and you certainly don't want all features to be available without having some way to identify the human behind the actions.

To put this in practical terms, let's imagine you're building a blogging platform.

Users that are quite human (like coming from Google or Apple) get all features. This is because you could, eventually, sue them for harassment, pornography, etc.

But users in "demo mode" don't get all features. Maybe they can only:

• Write blog posts as drafts, but not publish them. (Goal: Users should experience the great writing experience.)
  • This can be achieved by, for example, restricting INSERT and UPDATE on the public.posts table when auth.jwt()->>'is_anonymous' is true.
• Don't allow users to attach pictures to posts. (Goal: Storage costs money, and you don't want anonymous users to upload inappropriate content.)
  • Use Storage RLS policies to restrict uploads when is_anonymous is true.
• Prevent anonymous users from commenting on the blogging platform, but being able to read all comments. (Goal: Keep an orderly platform.)
  • This can be achieved by restricting INSERT on the public.comments table but allow SELECT when is_anonymous is true.

Resources:

• Postgres RLS policies (permissive vs restrictive): https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• Supabase Anonymous sign-ins docs: https://supabase.com/docs/guides/auth/auth-anonymous
• Storage access control (RLS): https://supabase.com/docs/guides/storage/security/access-control