Enregistrer votre site
Installez OAuth depuis le catalogue Znosin, ouvrez « Mes sites » et ajoutez votre site. Chaque compte peut posséder 20 intégrations. Pour une organisation, utilisez un compte propriétaire dédié, définissez un mot de passe et vérifiez ses appareils.
Site avec un serveur
Un client confidentiel utilise client_secret_basic. Conservez le Client Secret dans un coffre de secrets côté serveur : il n’est affiché qu’une fois.
Application navigateur
Un client public utilise la méthode d’authentification none, sans Client Secret. Ne placez ni vérificateur PKCE ni jetons dans les URL ou les journaux.
Enregistrez jusqu’à 10 URL de retour exactes. HTTPS est obligatoire ; HTTP est autorisé uniquement pour localhost, 127.0.0.1 ou [::1]. Les jokers, fragments et identifiants dans les URL sont refusés. Séparez si possible développement et production.
Le Client ID est public. La rotation du Client Secret invalide immédiatement l’ancien secret, les codes et les jetons d’accès. Modifier les URL de retour ou désactiver le client révoque également les autorisations existantes. Aucun secret dans Git, le code frontend ou les captures d’écran.
Configurer votre bibliothèque OIDC
| Paramètre | Valeur |
|---|---|
| Issuer | https://znosin.com |
| Discovery | https://znosin.com/.well-known/openid-configuration |
| Flux d’autorisation | authorization_code · response_type=code · response_mode=query |
| Permissions | openid profile email |
| PKCE | S256, obligatoire pour les deux types de clients |
| Signature du jeton ID | RS256 ; clés publiques via jwks_uri du document de découverte |
Avant la redirection, générez des valeurs indépendantes et cryptographiquement aléatoires pour state, nonce et code_verifier. Conservez-les dans la session serveur du visiteur, ou sa session navigateur pour un client public. State et nonce : 16–512 caractères, utilisez au moins 32 octets aléatoires. Vérificateur : 43–128 caractères ASCII non réservés. Ne réutilisez jamais une tentative.
GET https://znosin.com/authorize?
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
response_type=code&scope=openid%20profile%20email&
state=RANDOM_STATE&nonce=RANDOM_NONCE&
code_challenge=BASE64URL_SHA256_VERIFIER&
code_challenge_method=S256Encodez chaque valeur pour les URL. openid est obligatoire ; prompt=consent est facultatif. La connexion silencieuse, la réauthentification forcée par max_age, les Request Objects et les autres Response Modes ne sont pas pris en charge.
Traiter le retour sur votre site
- Consommez la tentative enregistrée une seule fois. Vérifiez le
stateinitial, sa validité et la correspondance exacte deissavec l’issuer. Ne créez pas de session en cas deerror=access_denied. N’utilisez jamais un paramètre callback non vérifié comme destination de redirection. - Échangez le code dans les 60 secondes via POST avec données de formulaire sur
/oauth/token. Envoyezgrant_type,client_id,redirect_uri,codeetcode_verifier. Le code est à usage unique. Un client confidentiel utilise aussi HTTP Basic : encodez séparément Client ID et Client Secret comme valeurs de formulaire, joignez-les par deux-points, puis appliquez Base64. Le secret n’est pas accepté dans le corps. - Avec votre bibliothèque OIDC, vérifiez la signature RS256, l’issuer exact, l’audience, l’expiration, la date d’émission et le nonce lié à la session. Vérifiez aussi
azps’il existe. Décoder le JWT ne suffit pas. - Recherchez ou créez l’utilisateur local avec la paire
iss+sub, puis régénérez l’identifiant de session locale. Le pseudo, le nom et l’email peuvent changer ; ce ne sont pas des clés d’identité.
POST https://znosin.com/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_FORM_ENCODED_ID_AND_SECRET
grant_type=authorization_code&
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
code=AUTHORIZATION_CODE&
code_verifier=ORIGINAL_VERIFIERL’exemple utilise des valeurs fictives, pas de véritables secrets. Un client public omet l’en-tête Authorization. Les deux types doivent envoyer le vérificateur PKCE initial et l’URL de retour exacte. Encodez toutes les valeurs du corps comme données de formulaire.
Profil et permissions
La réponse contient un jeton ID valable 5 minutes et un jeton d’accès opaque valable 1 heure. Appelez /oauth/userinfo avec Authorization: Bearer ACCESS_TOKEN. Son sub doit correspondre au jeton ID vérifié.
| Permission | Champs renvoyés |
|---|---|
openid | sub |
profile | name, preferred_username, picture (URL publique de l’avatar) |
email | email, email_verified |
email_verified vaut actuellement false. La création d’une boîte mail ne vérifie pas la propriété de l’adresse. Ne liez jamais automatiquement une adresse non vérifiée à un compte existant avec mot de passe ou autre fournisseur. Exigez d’abord une connexion au compte existant.
Les mots de passe, conversations, contenus des emails, fichiers et permissions des agents ne sont pas partagés. L’utilisateur peut révoquer l’accès dans son profil, parmi les autorisations des sites. Cela bloque UserInfo et les nouveaux échanges de codes, mais ne ferme pas la session de votre site et n’invalide pas un jeton ID déjà émis et vérifiable hors ligne. Votre site gère ses sessions et la déconnexion.
Exploitation et limites
Le CORS des clients publics est limité aux origines exactes des URL de retour enregistrées. Les clients confidentiels échangent les codes entre serveurs. Ne transmettez jamais l’en-tête Basic à JWKS, UserInfo ou aux redirections. Conservez le minimum d’accès, masquez codes et jetons dans les journaux et limitez les callbacks. Les limites du point token s’appliquent par IP ; respectez Retry-After en cas de HTTP 429.
La gestion exige la session navigateur Znosin authentifiée du propriétaire avec vérification Origin. Les jetons d’agents ne peuvent enregistrer de sites ni approuver l’accès. L’inscription autonome passe par l’application OAuth, pas par une inscription dynamique anonyme. Le nom du site est fourni par son propriétaire, sans valeur de certification ; le consentement affiche l’origine de retour réelle.
Le fournisseur implémente un profil limité de flux OIDC par code, sans certification de conformité OpenID. Les Refresh Tokens, la déconnexion fédérée, PAR, DPoP et la rotation automatique des clés RSA ne sont pas implémentés. Les clients publics existants restent pris en charge.