Skip to main content

Introduction

Intro to Auth

Current setup​

2 Github repos:

  1. auth-ui Main repo for our auth, hosted at auth.abair.ie Contains information sheets and consent forms signed off by COllege DPO. All other ABAIR sites should direct auth to this site. This site signs them in, redirects to an auth/handler at the original site with access and refresh tokens provided by Supabase on signin.
  2. auth-demo Simulates what all our front ends should be doing. this simple site contains only login which redirects to the auth site, with query params of sitename.ie/auth/callback it contains a callback function, which takes the access and refresh token, logs in to supabase, and redirects to suitable page.

Client-Side Authentification​

The Abair Auth system utalizes SupaBases Authentification API to sign up users with a variety of sign up methods, email, github, magic link etc.. When a new user creates an account using a pages 'log in/sign up' button they are directed to auth.abair.ie. The new user can then navigate to the sign up button at the bottom of the page.

Auth Home Page

From there they will begin creating their account. The proccess differs slightly based on whether the new user is older than 16 or not, due to GDPR reasons. Users below 16 will require a parent/caregivers email to sign up and will sign extra terms and conditions. Once all t's are crossed and i's dotted, the user will populate their profile prefrences and details, age, dialect etc.. When all that is complete, the user will be redirected to the page that they signed up to via a CallBack Function.

For all users that sign up, SupaBase generates a JWT or java web token called the access_token that contains the users encoded data, for example

 json { "aud": "authenticated", "exp": 1615824388, "sub": "0334744a-f2a2-4aba-8c8a-6e748f62a172", "email": "valid.email@supabase.io", "app_metadata": { "provider": "email" }, "user_metadata": null, "role": "authenticated" }

This access_token is stored in the users local memory, cached in their browser. Everytime the user makes a request to fetch data, this token is passed to SupaBases Authorization which grants access to the user based on their role and what data they have permission to obtain. When these access_tokens expire, as determined by the expiration field in the json, SupaBase will use a refresh_token to automatically generate a new valid JWT.

Access to specific rows of the Abair Tables is determined by RLS or row level security policies. RLS restricts access to specific rows of a table based on the user making the request. More specifically the users access_token. These policies can be created via the Table Editor. Simply navigate to the table you wish to create a policy for and press the add RLS Policy button.

Table Editor Page

This promt will allow you to create a RLS policy by choosing from a number of templates or writing the behaviour in SQL. Without RLS enabled, all authenticated users will be granted access to ALL rows of the table, so be sure to enable and grant the correct permissions!