Créer deux application routes

Votre application a généralement besoin :

d’une Login Route qui génère state, nonce et les valeurs PKCE avant la redirection vers DocID^®

d’une Callback Route qui valide la response, échange le code, lit les claims autorisés et crée une session locale

Stockez les données d’autorisation temporaires dans un cookie signé, HTTP-only, Secure et SameSite, ou dans un transaction store server-side.

1response_type=code2client_id=YOUR_CLIENT_ID3redirect_uri=https://your-domain.example/auth/docid/callback4scope=openid profile email5state=RANDOM_UNGUESSABLE_VALUE6nonce=RANDOM_UNGUESSABLE_VALUE7code_challenge=BASE64URL_SHA256_CODE_VERIFIER8code_challenge_method=S256

Traiter le callback

Sur le serveur :

rejetez les callbacks dont la valeur state est absente ou incorrecte.

gérez une response OAuth error sans exposer de détails techniques à l’utilisateur.

échangez l’Authorization Code auprès de /oauth2/token.

envoyez le code_verifier d’origine.

appelez /oauth2/userinfo avec l’Access Token.

associez sub au compte local ou à la session.

supprimez les données temporaires de la transaction OAuth.

Bien démarrer

Site web sur mesure

Préparez un site web rendu côté serveur ou une application web pour OAuth avec DocID^®.

Utilisez une intégration sur mesure si votre plateforme n’est pas WordPress ou si vous avez besoin d’un contrôle direct sur les sessions, le routing et le comportement basé sur le profil.

Prérequis

Un backend capable de préserver la confidentialité des credentials et des tokens
Des Callback Routes HTTPS
Un mécanisme de session server-side
Un client DocID^® pour chaque environnement

Créer deux application routes

Votre application a généralement besoin :

d’une Login Route qui génère state, nonce et les valeurs PKCE avant la redirection vers DocID^®
d’une Callback Route qui valide la response, échange le code, lit les claims autorisés et crée une session locale

Stockez les données d’autorisation temporaires dans un cookie signé, HTTP-only, Secure et SameSite, ou dans un transaction store server-side.

Demander l’autorisation

Redirigez le navigateur vers /oauth2/authorize avec :

1response_type=code2client_id=YOUR_CLIENT_ID3redirect_uri=https://your-domain.example/auth/docid/callback4scope=openid profile email5state=RANDOM_UNGUESSABLE_VALUE6nonce=RANDOM_UNGUESSABLE_VALUE7code_challenge=BASE64URL_SHA256_CODE_VERIFIER8code_challenge_method=S256

Traiter le callback

Sur le serveur :

rejetez les callbacks dont la valeur state est absente ou incorrecte.
gérez une response OAuth error sans exposer de détails techniques à l’utilisateur.
échangez l’Authorization Code auprès de /oauth2/token.
envoyez le code_verifier d’origine.
appelez /oauth2/userinfo avec l’Access Token.
associez sub au compte local ou à la session.
supprimez les données temporaires de la transaction OAuth.

Voir le flow OAuth 2.0 complet