Déployez-le. Connectez votre produit. Exploitez-le en sécurité.

À qui s’adresse ce manuel

Ce manuel comporte deux parcours indépendants. Les opérateurs peuvent terminer le parcours de déploiement sans être développeurs d’applications. Les équipes produit peuvent commencer par le parcours développeur dès qu’un issuer OpenProof sain existe.

Partie I — Déployer et configurer

1. Installer le runtime précompilé vérifié

curl -fsSL https://genyleap.com/install/openproof | sudo sh

L’installateur de production détecte Ubuntu/Debian et l’architecture CPU pris en charge, résout une release, télécharge le bundle précompilé correspondant et vérifie son manifeste SHA-256. Il n’installe pas de compilateur et ne revient pas silencieusement à une compilation depuis les sources.

2. Choisir l’identity origin

Utilisez un hostname public stable tel que auth.example.com. Il devient l’issuer OIDC et la base des callbacks fournisseurs.

issuer:   https://auth.example.com
callback: https://auth.example.com/auth/federated/callback
discovery:https://auth.example.com/.well-known/openid-configuration
jwks:     https://auth.example.com/.well-known/jwks.json

3. PostgreSQL et secrets

Choisissez PostgreSQL local pour un déploiement compact sur un seul hôte ou fournissez une postgres:// / postgresql:// URL existante. OpenProof applique des migrations avec checksum avant d’ouvrir le listener. L’installateur génère des secrets dédiés pour signature, chiffrement, pepper, audit, metrics et livraison avec des permissions restreintes.

4. Configurer la livraison de vérification

sudo openproof config delivery

5. Configurer les fournisseurs de connexion

Sélectionnez uniquement les fournisseurs dont les véritables identifiants sont prêts. Google, GitHub, Microsoft, Apple, LinkedIn, Telegram, X, Ethereum et Farcaster peuvent être configurés plus tard sans réinstaller OpenProof.

sudo openproof config providers

Les placeholders courants tels que 0, test, dummy, example and placeholder sont traités comme une configuration différée et non comme de véritables identifiants fournisseur.

6. Configurer l’upstream de l’application protégée

OpenProof gateway
    ↓
127.0.0.1:3000
    ↓
your product backend

Le backend produit n’a pas besoin d’être en cours d’exécution pour que le plan identity/OAuth d’OpenProof soit sain. Modifiez les paramètres gateway/upstream avec sudo openproof config main.

7. TLS et ingress

Utilisez Let’s Encrypt pour un vrai nom DNS public, fournissez un certificat existant ou terminez TLS sur votre propre ingress/load balancer. Les noms réservés tels que *.example.com, *.test and *.invalid utilisent par défaut TLS externe/différé plutôt qu’une demande de certificat public vouée à l’échec.

8. Vérifier la santé

sudo openproof status
openproof status --full
sudo openproof doctor

Lors d’un test manuel du listener loopback en mode trusted-proxy, envoyez l’adresse client locale transférée :

curl -fsS \
  -H 'X-Forwarded-For: 127.0.0.1' \
  http://127.0.0.1:18443/health/ready

{"status":"ok"}

Partie II — Développer avec OpenProof

L’intégration produit utilise OAuth 2.0/OpenID Connect. Les applications reçoivent des tokens OAuth/OIDC ; elles ne copient pas le cookie de session navigateur OpenProof dans leur propre domaine.

User
  ↓
your app
  ↓ redirect
OpenProof /oauth/authorize
  ↓ authenticate
your callback ?code=...&state=...&iss=...
  ↓ code + PKCE verifier
OpenProof /oauth/token
  ↓
access_token + id_token + optional refresh_token

1. Enregistrer une application et un client

Un propriétaire IAL2 actif peut utiliser /admin/console ou l’API d’administration. Choisissez le type de client correspondant à votre produit.

2. Utiliser Authorization Code + PKCE

Générez un verifier à forte entropie, un challenge PKCE S256 et des valeurs aléatoires pour state et une valeur aléatoire nonce. Au callback, validez state et l’issuer renvoyé avant d’échanger le code.

curl --fail-with-body https://auth.example.com/oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=authorization_code' \
  --data-urlencode 'client_id=CLIENT_ID' \
  --data-urlencode 'code=AUTHORIZATION_CODE' \
  --data-urlencode 'redirect_uri=https://app.example.com/oauth/callback' \
  --data-urlencode 'code_verifier=PKCE_VERIFIER'

3. Valider les tokens OIDC

Ne vous contentez pas de décoder le ID token. Vérifiez RS256 avec le JWKS de l’issuer et validez iss, aud, exp, iat et la valeur originale nonce ; respectez également nbf, azp and at_hash lorsqu’ils sont présents.

4. Travailler dans votre langage

5. Protéger les API

Enregistrez une ressource avec une audience et des scopes, puis validez/introspectez les access tokens dans votre backend ou placez les routes derrière le gateway OpenProof. L’autorisation produit doit être plus stricte que « token valide » : vérifiez audience, scope et politique métier.

6. Service à service

Utilisez un service client avec client_credentials. Il reçoit uniquement un access token — aucune session humaine et aucun refresh token.

Checklist de production

• Un vrai DNS et un HTTPS de confiance sont en place.
• Des sauvegardes PostgreSQL existent et un exercice de restauration a été testé.
• La livraison de vérification utilise un vrai SMTP relay/webhook plutôt que des hostnames d’exemple.
• Le propriétaire initial est protégé par MFA/TOTP.
• Les callbacks fournisseurs correspondent exactement à l’identity origin de production.
• Les OAuth redirect URI sont exactes et la validation PKCE/state/nonce est activée.
• Les ID tokens sont validés côté signature/claims ; les access tokens sont autorisés selon audience et scope.
• La rotation des refresh tokens est persistée atomiquement.
• La readiness est surveillée et openproof doctor réussit après les changements d’infrastructure.
• Les secrets provider/client/database/signing n’entrent jamais dans le source control, les logs ou les prompts AI.

Référence