mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
Danny White
24be387cdb
## What kind of change does this PR introduce? Docs update. Aligns documentation and style guides with the **Sign in / Sign out / Sign up** platform standard. Closes DOCS-1328. Related to [#49874](https://github.com/supabase/supabase/pull/49874). ## What is the current behavior? Docs style guides prefer _login_ / _log in_. Guide prose uses mixed login and sign in wording. ## What is the new behavior? - [WORD_LIST.md](apps/docs/WORD_LIST.md) and [copywriting.mdx](apps/design-system/content/docs/copywriting.mdx) document the sign in standard - Design-system auth examples updated - Guide prose and API reference spec descriptions updated ### Terminology **Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use _sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match Studio UI labels (**Sign in**, **Sign out**, **Sign up**). **Preserved intentionally:** | Category | Keep as-is | Example | | -------- | ---------- | ------- | | Feature name | social login | `/social-login`, `features.mdx` heading, OAuth provider section | | URL slugs | `login` in paths | `/phone-login`, `/login-flows`, `choosing-login-flow` | | CLI | `supabase login` / `supabase logout` | Reference ids `supabase-login` / `supabase-logout`; executable commands unchanged | | SDK methods | `logout()` | Kotlin/Swift method names in API reference titles and examples | | Third-party UI | Provider product labels | Facebook Login, Kakao Login, portal **Login** buttons | | Postgres | Database terminology | login privileges, login credentials, login via role | | Audit/logging | Log prose | "Generates the following **log** in the Postgres Logs" | | Code and routes | Paths and filenames | `app/login/`, `Login.tsx`, `demos/android-login` | | External URLs | Third-party login pages | `dash.cloudflare.com/login`, `console.neon.tech/login`, `vercel.com/login` | | API identifiers | Event and field names | Audit actions `login`/`logout`, `should_logout_user` | ## To test - Run `pnpm lint:mdx` in `apps/docs` - Spot-check `features.mdx`, `social-login.mdx`, and a provider guide (e.g. Facebook, Kakao) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Standardized authentication terminology across guides, reference material, CLI documentation, and copywriting guidance using “sign in,” “sign out,” and “sign up.” * Updated authentication instructions, headings, link text, examples, and SSO guidance for clearer, more consistent wording. * Corrected related grammar, spelling, hyphenation, and documentation links while preserving established product names and implementation commands. * **Style** * Refined code examples with consistent import ordering and spacing. * **Examples** * Updated authentication button and menu labels to “Sign in” and “Sign out.” <!-- end of auto-generated comment: release notes by coderabbit.ai -->
73 lines
3.4 KiB
Plaintext
73 lines
3.4 KiB
Plaintext
---
|
|
title: 'Auth architecture'
|
|
subtitle: 'The architecture behind Supabase Auth.'
|
|
---
|
|
|
|
There are four major layers to Supabase Auth:
|
|
|
|
1. [Client layer.](#client-layer) This can be one of the Supabase client SDKs, or manually made HTTP requests using the HTTP client of your choice.
|
|
1. Envoy API gateway. This is shared between all Supabase products.
|
|
1. [Auth service](#auth-service) (formerly known as GoTrue).
|
|
1. [Postgres database.](#postgres) This is shared between all Supabase products.
|
|
|
|
<Image
|
|
alt="Diagram showing the architecture of Supabase. The Envoy API gateway sits in front of 7 services: GoTrue, PostgREST, Realtime, Storage, pg_meta, Functions, and pg_graphql. All the services talk to a single Postgres instance."
|
|
src={{
|
|
dark: '/docs/img/supabase-architecture.svg',
|
|
light: '/docs/img/supabase-architecture--light.svg',
|
|
}}
|
|
width={1600}
|
|
height={767}
|
|
/>
|
|
|
|
## Client layer
|
|
|
|
The client layer runs in your app. This could be running in many places, including:
|
|
|
|
- Your frontend browser code
|
|
- Your backend server code
|
|
- Your native application
|
|
|
|
The client layer provides the functions that you use to sign in and manage users. We recommend using the Supabase client SDKs, which handle:
|
|
|
|
- Configuration and authentication of HTTP calls to the Supabase Auth backend
|
|
- Persistence, refresh, and removal of Auth Tokens in your app's storage medium
|
|
- Integration with other Supabase products
|
|
|
|
But at its core, this layer manages the making of HTTP calls, so you could write your own client layer if you wanted to.
|
|
|
|
See the Client SDKs for more information:
|
|
|
|
- [JavaScript](/docs/reference/javascript/introduction)
|
|
- [Flutter](/docs/reference/dart/introduction)
|
|
- [Swift](/docs/reference/swift/introduction)
|
|
- [Python](/docs/reference/python/introduction)
|
|
- [C#](/docs/reference/csharp/introduction)
|
|
- [Kotlin](/docs/reference/kotlin/introduction)
|
|
|
|
## Auth service
|
|
|
|
The [Auth service](https://github.com/supabase/auth) is an Auth API server written and maintained by Supabase. It is a fork of the GoTrue project, originally created by Netlify.
|
|
|
|
When you deploy a new Supabase project, we deploy an instance of this server alongside your database, and inject your database with the required Auth schema.
|
|
|
|
The Auth service is responsible for:
|
|
|
|
- Validating, issuing, and refreshing JWTs
|
|
- Serving as the intermediary between your app and Auth information in the database
|
|
- Communicating with external providers for social login and SSO
|
|
|
|
## Postgres
|
|
|
|
Supabase Auth uses the `auth` schema in your Postgres database to store user tables and other information. For security, this schema is not exposed on the auto-generated API.
|
|
|
|
You can connect Auth information to your own objects using [database triggers](/docs/guides/database/postgres/triggers) and [foreign keys](https://www.postgresql.org/docs/current/tutorial-fk.html). Make sure that any views you create for Auth data are adequately protected by [enabling RLS](/docs/guides/database/postgres/row-level-security) or [revoking grants](https://www.postgresql.org/docs/current/sql-revoke.html).
|
|
|
|
<Admonition type="danger">
|
|
|
|
Make sure any views you create for Auth data are protected.
|
|
|
|
Starting in Postgres version 15, views inherit the RLS policies of the underlying tables if created with `security_invoker`. Views in earlier versions, or those created without `security_invoker`, inherit the permissions of the owner, who can bypass RLS policies.
|
|
|
|
</Admonition>
|