Auth - Authentification et gestion des utilisateurs par Supabase

Auth est un serveur de gestion des utilisateurs et d'authentification écrit en Go qui alimente les fonctionnalités de Supabase, telles que :

• Émission de JWT
• Sécurité au niveau des lignes avec PostgREST
• Gestion des utilisateurs
• Connexion par e-mail, mot de passe, lien magique, numéro de téléphone
• Connexion avec des fournisseurs externes (Google, Apple, Facebook, Discord, ...)

Il est à l'origine basé sur l'excellente base de code GoTrue de Netlify, mais les deux ont considérablement divergé en termes de fonctionnalités et de capacités.

Si vous souhaitez contribuer au projet, veuillez vous référer au guide de contribution.

Table des matières

• Démarrage rapide
• Exécution en production
• Configuration
• Endpoints

Démarrage rapide

Créez un fichier .env pour stocker vos propres variables d'environnement personnalisées. Voir example.env

1. Démarrez la base de données Postgres locale dans un conteneur Postgres : docker-compose -f docker-compose-dev.yml up postgres
2. Compilez le binaire auth : make build . Vous devriez voir une sortie similaire à ceci :```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. Exécutez le binaire auth : `./auth`

### Si vous avez Docker installé

Créez un fichier `.env.docker` pour stocker vos propres variables d'environnement personnalisées. Voir [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env)

1. `make build`
2. `make dev`
3. `docker ps` devrait afficher deux conteneurs Docker (`auth-auth-1` et `auth-postgres-1`)
4. C'est tout ! Visitez l'[endpoint de vérification de santé](http://localhost:9999/health) pour confirmer qu'auth fonctionne.

## Exécution en production

Exécuter un serveur d'authentification en production n'est pas une tâche facile. Nous recommandons d'utiliser [Supabase Auth](https://supabase.com/auth), qui bénéficie de mises à jour de sécurité régulières.

Sinon, veuillez vous assurer de mettre en place un processus pour mettre à jour rapidement vers la dernière version. Vous pouvez le faire en suivant ce dépôt, en particulier les sections [Releases](https://github.com/supabase/auth/releases) et [Security Advisories](https://github.com/supabase/auth/security/advisories).

### Rétrocompatibilité

Auth utilise le schéma [Semantic Versioning](https://semver.org). Voici quelques précisions supplémentaires sur les garanties de rétrocompatibilité :

**Compatibilité de l'API Go**

Auth n'est pas conçu pour être utilisé comme une bibliothèque Go. Il n'y a aucune garantie de compatibilité API ascendante lorsqu'il est utilisé de cette manière, quel que soit le numéro de version modifié.

**Patch**

Les modifications apportées à la version de patch garantissent la rétrocompatibilité avec :

- Les objets de base de données (tables, colonnes, index, fonctions).
- REST API
- La structure des JWT
- La configuration

Exemples garantis :

- Une colonne ne changera pas de type.
- Une table ne changera pas sa clé primaire.
- Un index ne sera pas supprimé.
- Une contrainte d'unicité ne sera pas supprimée.
- Une API REST ne sera pas supprimée.
- Les paramètres des API REST fonctionneront de manière équivalente à avant (ou mieux, si un bug a été corrigé).
- La configuration ne changera pas.

Exemples non garantis :

- Une table peut ajouter de nouvelles colonnes.
- Les colonnes d'une table peuvent être réordonnées.
- Des contraintes non uniques peuvent être supprimées (vérifications au niveau de la base de données, valeurs null, valeurs par défaut).
- Les JWT peuvent ajouter de nouvelles propriétés.

**Mineur**

Les modifications apportées à la version mineure garantissent la rétrocompatibilité avec :

- REST API
- La structure des JWT
- La configuration

Des exceptions à ces garanties ne seront faites que lorsque de graves problèmes de sécurité seront découverts et ne pourront être corrigés d'aucune autre manière.

Exemples garantis :

- Les API existantes peuvent être dépréciées mais continueront de fonctionner pendant les prochaines versions mineures.
- Les modifications de configuration peuvent être dépréciées mais continueront de fonctionner pendant les prochaines versions mineures.
- Les JWT déjà émis seront acceptés, mais les nouveaux JWT peuvent avoir une structure différente (mais généralement similaire).

Exemples non garantis :

- La suppression de champs JWT après un avis de dépréciation.
- La suppression de certaines API après un avis de dépréciation.
- La suppression de la connexion avec des fournisseurs externes, après un avis de dépréciation.
- La suppression, la troncature ou des modifications importantes de schéma sur les tables, index, vues et fonctions.

Nous visons à fournir un avis de dépréciation dans les journaux d'exécution pendant au moins deux versions majeures, ou deux semaines si plusieurs versions sont publiées. La compatibilité sera garantie tant que l'avis est actif.

**Majeur**

Les modifications apportées à la version majeure ne garantissent aucune rétrocompatibilité avec les versions précédentes.

### Fonctionnalités héritées

Certaines fonctionnalités héritées de la base de code Netlify ne sont pas prises en charge par Supabase et peuvent être supprimées sans préavis à l'avenir. Voici une liste complète de ces fonctionnalités :

1. La multi-tenant via la table `instances`, c'est-à-dire le paramètre de configuration `GOTRUE_MULTI_INSTANCE_MODE`.
2. L'utilisateur système (utilisateur UUID zéro).
3. Le super administrateur via la colonne `is_super_admin`.
4. Les informations de groupe dans les JWT via `GOTRUE_JWT_ADMIN_GROUP_NAME` et d'autres champs de configuration.
5. La signature JWT. Supabase Auth prend en charge les clés asymétriques (RS256 par défaut ; ECC/Ed25519 en option). HS256 est toujours pris en charge pour la compatibilité, mais la migration vers des clés asymétriques est recommandée pour une validation et une rotation plus faciles. Les dépréciations futures seront annoncées dans le journal des modifications. Voir les [JWT Signing Keys](https://supabase.com/docs/guides/auth/signing-keys) et le [guide des JWT](https://supabase.com/docs/guides/auth/jwts) pour plus de détails.

Notez que cette liste n'est pas exhaustive et peut changer.

### Meilleures pratiques pour l'auto-hébergement

Voici quelques bonnes pratiques à suivre lors de l'auto-hébergement pour garantir la rétrocompatibilité avec Auth :

1. Ne modifiez pas le schéma géré par Auth. Vous pouvez voir toutes les migrations dans le répertoire `migrations`.
2. Ne vous fiez pas au schéma ni à la structure des données dans la base de données. Utilisez toujours les API Auth et les JWT pour déduire des informations sur les utilisateurs.
3. Exécutez toujours Auth derrière un proxy compatible TLS tel qu'un équilibreur de charge, un CDN, nginx ou un autre logiciel similaire.

## Configuration

Vous pouvez configurer Auth à l'aide d'un fichier de configuration nommé `.env`, de variables d'environnement, ou d'une combinaison des deux. Les variables d'environnement sont préfixées par `GOTRUE_` et ont toujours la priorité sur les valeurs fournies via le fichier.

### Niveau supérieur```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string required