Auth - Autenticação e Gerenciamento de Usuários do Supabase

Auth é um servidor de gerenciamento de usuários e autenticação escrito em Go que alimenta os recursos do Supabase, tais como:

• Emissão de JWTs
• Segurança em Nível de Linha com PostgREST
• Gerenciamento de usuários
• Entrar com e-mail, senha, link mágico, número de telefone
• Entrar com provedores externos (Google, Apple, Facebook, Discord, ...)

Ele é originalmente baseado no excelente código-fonte do GoTrue da Netlify, no entanto, ambos divergiram significativamente em recursos e capacidades.

Se você deseja contribuir com o projeto, consulte o guia de contribuição.

Índice

• Início Rápido
• Executando em Produção
• Configuração
• Endpoints

Início Rápido

Crie um arquivo .env para armazenar suas próprias variáveis de ambiente personalizadas. Consulte example.env

1. Inicie o banco de dados Postgres local em um contêiner Postgres: docker-compose -f docker-compose-dev.yml up postgres
2. Compile o binário auth: make build . Você deve ver uma saída como esta:```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. Execute o binário auth: `./auth`

### Se você tiver o Docker instalado

Crie um arquivo `.env.docker` para armazenar suas próprias variáveis de ambiente personalizadas. Veja [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env)

1. `make build`
2. `make dev`
3. `docker ps` deve mostrar dois contêineres Docker (`auth-auth-1` e `auth-postgres-1`)
4. É isso! Visite o [endpoint de verificação de saúde](http://localhost:9999/health) para confirmar que o auth está em execução.

## Executando em produção

Executar um servidor de autenticação em produção não é uma tarefa fácil. Nós
recomendamos usar o [Supabase Auth](https://supabase.com/auth), que recebe
atualizações regulares de segurança.

Caso contrário, certifique-se de configurar um processo para atualizar prontamente para a
versão mais recente. Você pode fazer isso acompanhando este repositório, especificamente as
seções [Releases](https://github.com/supabase/auth/releases) e [Security
Advisories](https://github.com/supabase/auth/security/advisories).

### Compatibilidade com versões anteriores

Auth usa o esquema de [Versionamento Semântico](https://semver.org). Aqui estão algumas
esclarecimentos adicionais sobre as garantias de compatibilidade com versões anteriores:

**Compatibilidade com a API Go**

Auth não foi projetado para ser usado como uma biblioteca Go. Não há garantias de
compatibilidade retroativa da API quando usado dessa forma, independentemente do
número da versão que mudar.

**Patch**

Alterações na versão de patch garantem compatibilidade com versões anteriores com:

- Objetos de banco de dados (tabelas, colunas, índices, funções).
- API REST
- Estrutura do JWT
- Configuração

Exemplos garantidos:

- Uma coluna não mudará seu tipo.
- Uma tabela não mudará sua chave primária.
- Um índice não será removido.
- Uma restrição de unicidade não será removida.
- Uma API REST não será removida.
- Os parâmetros das APIs REST funcionarão de forma equivalente a antes (ou melhor, se um bug
  tiver sido corrigido).
- A configuração não mudará.

Exemplos não garantidos:

- Uma tabela pode adicionar novas colunas.
- As colunas de uma tabela podem ser reordenadas.
- Restrições não únicas podem ser removidas (verificações de nível de banco de dados, valores nulos, valores
  padrão).
- O JWT pode adicionar novas propriedades.

**Minor**

Alterações na versão minor garantem compatibilidade com versões anteriores com:

- API REST
- Estrutura do JWT
- Configuração

Exceções a essas garantias só serão feitas quando problemas graves de segurança
forem encontrados e não puderem ser remediados de outra forma.

Exemplos garantidos:

- APIs existentes podem ser descontinuadas, mas continuarão funcionando pelas próximas
  versões minor.
- Alterações de configuração podem ser descontinuadas, mas continuarão funcionando pelas
  próximas versões minor.
- JWTs já emitidos serão aceitos, mas novos JWTs podem ter uma estrutura diferente
  (mas geralmente semelhante).

Exemplos não garantidos:

- Remoção de campos do JWT após um aviso de descontinuação.
- Remoção de certas APIs após um aviso de descontinuação.
- Remoção do login com provedores externos, após um aviso de descontinuação.
- Exclusão, truncamento, alterações significativas de esquema em tabelas, índices, visões,
  funções.

Nosso objetivo é fornecer um aviso de descontinuação nos logs de execução por pelo menos duas
versões principais ou duas semanas se várias versões forem lançadas. A compatibilidade será
garantida enquanto o aviso estiver ativo.

**Major**

Alterações na versão major não garantem nenhuma compatibilidade com
as versões anteriores.

### Recursos herdados

Certos recursos herdados da base de código do Netlify não são suportados pelo
Supabase e podem ser removidos sem aviso prévio no futuro. Esta é uma
lista abrangente desses recursos:

1. Multi-tenência por meio da tabela `instances`, ou seja, `GOTRUE_MULTI_INSTANCE_MODE`
   parâmetro de configuração.
2. Usuário do sistema (usuário UUID zero).
3. Super administrador por meio da coluna `is_super_admin`.
4. Informações de grupo em JWTs por meio de `GOTRUE_JWT_ADMIN_GROUP_NAME` e outros
   campos de configuração.
5. Assinatura de JWT. O Supabase Auth suporta chaves assimétricas (RS256 por padrão;
   ECC/Ed25519 opcional). HS256 ainda é suportado para compatibilidade, mas
   a migração para chaves assimétricas é recomendada para validação e rotação
   mais fáceis. Futuras descontinuações serão anunciadas no changelog. Consulte as
   [Chaves de assinatura de JWT](https://supabase.com/docs/guides/auth/signing-keys) e
   o [guia de JWTs](https://supabase.com/docs/guides/auth/jwts) para obter detalhes.

Observe que esta não é uma lista exaustiva e ela pode mudar.

### Boas práticas ao fazer self-hosting

Estas são algumas boas práticas a seguir ao fazer self-hosting para garantir a
retrocompatibilidade com o Auth:

1. Não modifique o esquema gerenciado pelo Auth. Você pode ver todas as
   migrações no diretório `migrations`.
2. Não confie no esquema e na estrutura dos dados no banco de dados. Use sempre
   as APIs do Auth e JWTs para inferir informações sobre os usuários.
3. Execute sempre o Auth atrás de um proxy compatível com TLS, como um balanceador de carga, CDN,
   nginx ou outro software semelhante.

## Configuração

Você pode configurar o Auth usando um arquivo de configuração chamado `.env`,
variáveis de ambiente ou uma combinação de ambos. As variáveis de ambiente são prefixadas com `GOTRUE_` e sempre terão precedência sobre os valores fornecidos via arquivo.

### Nível superior```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string obrigatório

A URL base onde o seu site está localizado. Atualmente usada em combinação com outras configurações para construir URLs usadas em emails. Qualquer URI que compartilhe um host com SITE_URL é um valor permitido para os parâmetros redirect_to (consulte /authorize etc.).

URI_ALLOW_LIST - string