Auth - Аутентификация и управление пользователями от Supabase

Auth — это сервер аутентификации и управления пользователями, написанный на Go, который обеспечивает работу таких функций Supabase, как:

Выпуск JWT
Безопасность на уровне строк (Row Level Security) с PostgREST
Управление пользователями
Вход по email, паролю, magic link, номеру телефона
Вход через внешних провайдеров (Google, Apple, Facebook, Discord, ...)

Изначально он основан на отличном коде GoTrue от Netlify, однако с тех пор обе реализации значительно разошлись в возможностях и функциональности.

Если вы хотите внести вклад в проект, пожалуйста, обратитесь к руководству по внесению вклада.

Быстрый старт

Создайте файл .env для хранения собственных переменных окружения. См. example.env

Запустите локальную базу данных Postgres в контейнере Postgres: docker-compose -f docker-compose-dev.yml up postgres
Соберите бинарный файл auth: make build . Вы должны увидеть вывод, похожий на этот:```bash go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" GOOS=linux GOARCH=arm64 go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" -o gotrue-arm64

3. Выполните бинарный файл auth: `./auth`

### Если у вас установлен Docker

Создайте файл `.env.docker` для хранения собственных переменных окружения. См. [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env)

1. `make build`
2. `make dev`
3. `docker ps` должен показать два Docker-контейнера (`auth-auth-1` и `auth-postgres-1`)
4. Вот и всё! Перейдите к [конечной точке проверки состояния](http://localhost:9999/health), чтобы убедиться, что auth запущен.

## Запуск в производственной среде

Запуск сервера аутентификации в производственной среде — непростая задача. Мы
рекомендуем использовать [Supabase Auth](https://supabase.com/auth), который регулярно
получает обновления безопасности.

В противном случае убедитесь, что вы настроили процесс своевременного обновления до
последней версии. Это можно сделать, следя за этим репозиторием, в частности за
разделами [Releases](https://github.com/supabase/auth/releases) и [Security
Advisories](https://github.com/supabase/auth/security/advisories).

### Обратная совместимость

Auth использует схему [Semantic Versioning](https://semver.org). Ниже приведены
дополнительные разъяснения гарантий обратной совместимости:

**Совместимость Go API**

Auth не предназначен для использования в качестве библиотеки Go. Нет никаких гарантий
обратной совместимости API при таком использовании, независимо от того, какой номер
версии изменяется.

**Патч**

Изменения патч-версии гарантируют обратную совместимость с:

- объектами базы данных (таблицы, столбцы, индексы, функции).
- REST API
- структурой JWT
- конфигурацией

Гарантированные примеры:

- Столбец не изменит свой тип.
- Таблица не изменит свой первичный ключ.
- Индекс не будет удалён.
- Ограничение уникальности не будет удалено.
- REST API не будет удалён.
- Параметры REST API будут работать так же, как и раньше (или лучше, если ошибка
  была исправлена).
- Конфигурация не изменится.

Негарантированные примеры:

- Таблица может добавить новые столбцы.
- Столбцы в таблице могут быть переупорядочены.
- Неуникальные ограничения могут быть удалены (проверки на уровне базы данных, null, значения
  по умолчанию).
- JWT может добавлять новые свойства.

**Минорная версия**

Изменения минорной версии гарантируют обратную совместимость с:

- REST API
- структурой JWT
- конфигурацией

Исключения из этих гарантий допускаются только в тех случаях, когда обнаружены
серьёзные проблемы безопасности, которые невозможно устранить иным способом.

Гарантированные примеры:

- Существующие API могут быть объявлены устаревшими, но продолжат работать в течение следующих нескольких минорных
  выпусков версий.
- Изменения конфигурации могут быть объявлены устаревшими, но продолжат работать в течение следующих
  нескольких минорных выпусков версий.
- Уже выпущенные JWT будут приниматься, но новые JWT могут иметь другую
  структуру (но обычно аналогичную).

Негарантированные примеры:

- Удаление полей JWT после уведомления об устаревании.
- Удаление некоторых API после уведомления об устаревании.
- Удаление входа через внешних провайдеров после уведомления об устаревании.
- Удаление, усечение, существенные изменения схемы таблиц, индексов, представлений,
  функций.

Мы стремимся предоставлять уведомление об устаревании в журналах выполнения как минимум
для двух мажорных выпусков версий или в течение двух недель, если выходит несколько
релизов. Совместимость будет гарантироваться, пока уведомление активно.

**Мажорная версия**

Изменения мажорной версии не гарантируют обратной совместимости с
предыдущими версиями.

### Унаследованные функции

Некоторые унаследованные функции из кодовой базы Netlify не поддерживаются
Supabase и могут быть удалены без предварительного уведомления в будущем. Вот
полный список этих функций:

1. Мультиарендность через таблицу `instances`, т.е. `GOTRUE_MULTI_INSTANCE_MODE`
   параметр конфигурации.
2. Системный пользователь (пользователь с нулевым UUID).
3. Супер-администратор через столбец `is_super_admin`.
4. Информация о группах в JWT через `GOTRUE_JWT_ADMIN_GROUP_NAME` и другие
   поля конфигурации.
5. Подпись JWT. Supabase Auth поддерживает асимметричные ключи (RS256 по умолчанию;
   ECC/Ed25519 опционально). HS256 по-прежнему поддерживается для совместимости, но
   рекомендуется перейти на асимметричные ключи для упрощения проверки и
   ротации. Будущие удаления будут объявлены в журнале изменений. См.
   [JWT Signing Keys](https://supabase.com/docs/guides/auth/signing-keys) и
   [JWTs guide](https://supabase.com/docs/guides/auth/jwts) для подробностей.

Обратите внимание, что это не исчерпывающий список, и он может измениться.

### Рекомендации при самостоятельном размещении

Вот несколько рекомендаций, которым следует следовать при самостоятельном размещении,
чтобы обеспечить обратную совместимость с Auth:

1. Не изменяйте схему, управляемую Auth. Вы можете просмотреть все
   миграции в каталоге `migrations`.
2. Не полагайтесь на схему и структуру данных в базе данных. Всегда используйте
   API Auth и JWT для получения информации о пользователях.
3. Всегда запускайте Auth за прокси с поддержкой TLS, например балансировщиком нагрузки, CDN,
   nginx или другим подобным программным обеспечением.

## Конфигурация

Вы можете настроить Auth, используя файл конфигурации `.env`,
переменные окружения или их комбинацию. Переменные окружения имеют префикс `GOTRUE_` и всегда имеют приоритет над значениями, указанными в файле.

### Верхний уровень```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string обязательно

Базовый URL, по которому расположен ваш сайт. В настоящее время используется в сочетании с другими настройками для формирования URL-адресов, используемых в электронных письмах. Любой URI, у которого общий хост с SITE_URL, является допустимым значением для параметров redirect_to (см. /authorize и т.д.).

URI_ALLOW_LIST - string

auth v2.197.0

Auth - Аутентификация и управление пользователями от Supabase

Содержание

Быстрый старт

Категории