Documentation Frappe Framework

Frappe Framework

OAuth 2

authorize, get_token, revoke, profil OpenID et introspection. Le jeton d’identité est un JWT signé HS256 avec le secret du client.

2 min de lectureMis à jour le Source : docs.frappe.io

Jeton

Les appels authentifiés portent Authorization: Bearer et le jeton d’accès, RFC 6750. Le bureau du client est dans OAuth2 et Configurer OAuth 2. Une introduction vidéo est citée : 996OiexHze0.

Code d’autorisation

Le titre est GET /api/method/frappe.integrations.oauth2.authorize. L’exemple curl est un POST. Paramètres : client_id, state (renvoyé au callback, contre le CSRF), response_type égal à code, scope, redirect_uri. PKCE facultatif : code_challenge_method vaut s256 ou plain. code_challenge est base64encode(sha256(random_string)) ou la chaîne elle-même. RFC 7636.

L’exemple envoie client_id 511cb2ac2d, state 444, response_type code, scope openid all déjà encodé, redirect Postman. Un commentaire dit que le hash de 420 vaut 21XaP8MJjpxCMRxgEzBP82sZ73PRLqkyBUta1R309J0 et le place dans code_verifier, ligne commentée. Il manque une barre oblique inverse avant response_type dans le curl publié. Réponse 200, text/html, page d’autorisation. Allow redirige avec code et state. Deny renvoie error=access_denied.

Échange

POST /api/method/frappe.integrations.oauth2.get_token, corps application/x-www-form-urlencoded. Le même point rafraîchit si le corps contient refresh_token. Paramètres : grant_type authorization_code, code, client_id, redirect_uri. L’exemple a un saut de ligne au milieu du code. Pour tester, les paramètres peuvent aller dans l’URL, à ouvrir dans le navigateur. Réponse : access_token, token_type Bearer, expires_in 3600, refresh_token, scope openid all, id_token.

En PKCE, le corps ajoute code_verifier, la chaîne aléatoire de la demande. L’exemple met code_verifier=420, pas le hash commenté plus haut. Même forme de réponse.

Révocation, jeton d’identité, profil

POST revoke_token, paramètre token. Réponse toujours vide, HTTP 200.

L’id_token est un JWT. aud est le client_id, iss l’URL du serveur, sub l’identifiant utilisateur, roles les rôles, exp l’expiration, iat l’émission. PyJWT décode avec l’audience, la clé égale au client_secret, algorithme HS256. L’appel publié met verify_exp à False. Le commentaire dit que la vérification d’expiration est activée par défaut. Le payload d’exemple ajoute name, email, nonce, et les rôles System Manager et Sales Manager. iss vaut https://erp.example.com.

GET openid_profile, en-tête Bearer. La réponse ajoute given_name, family_name et picture.

POST introspect_token. Le paragraphe publié dit « Revoke token endpoint ». Paramètres : token_type_hint (access_token ou refresh_token, défaut access_token) et token. Si actif : client_id, trusted_client 1, active true, scope, et les mêmes claims. Le JSON publié répète exp deux fois, 1619523326 puis 1516242022. Sinon active false et _server_messages.

Point d’attention

Le titre authorize dit GET, l’exemple est POST. Le commentaire PKCE nomme code_verifier ce que la section défi décrit comme code_challenge. La révocation répond 200 même sans autre corps.