Saltar al contingut principal
Authentication és nova. Didit activa el producte per a la teva aplicació. Fins llavors, totes les rutes d’execució d’aquesta aplicació retornen 404. Els paquets de l’SDK d’Authentication encara no estan publicats, així que utilitza el flux allotjat i el contracte HTTP d’aquestes pàgines.
Authentication permet als teus clients iniciar sessió a la teva aplicació. És independent d’iniciar sessió a la consola de Didit o de crear un compte de desenvolupador de Didit. També és independent de verificar la identitat d’una persona. Utilitza Authentication sol o combina’l amb la Verificació d’identitat i el Monitoratge de transaccions. Iniciar sessió no aprova una verificació ni autoritza un pagament. El teu backend pren aquestes decisions a partir del resultat de cada producte.

​
Com funciona

Cada aplicació té el seu propi origen d’inici de sessió i el seu propi emissor de tokens. Les aplicacions de producció i les sandbox són independents: tenen orígens, configuracions i identitats separats. El flux utilitza el codi d’autorització d’OAuth 2.0 amb PKCE (només S256):
  1. La teva app obre {origin}/sign-in amb redirect_uri, state, code_challenge i code_challenge_method=S256.
  2. La pàgina allotjada inicia sessió o registra la persona amb els mètodes que hagis activat, incloent-hi qualsevol segon factor obligatori.
  3. El navegador torna al teu redirect_uri amb code i state.
  4. La teva app intercanvia el codi a POST {origin}/token/ per obtenir un token d’accés, un token d’ID i un token de refresc.
Consulta tokens i JWKS per al contracte de tokens i mètodes d’inici de sessió per a cada mètode.

​
Tria la teva plataforma

JavaScript

Inici de sessió allotjat, callback, sessió i tancament de sessió.

React

Estat al client i vistes protegides de l’aplicació.

Next.js

Sessions al servidor, rutes de callback i cookies.

iOS

Navegador del sistema i emmagatzematge segur de tokens.

Android

Autorització al navegador i callbacks de l’app.

React Native

Preparació de l’embolcall d’autenticació natiu.

Flutter

Preparació de l’embolcall d’autenticació natiu.

​
Prepara la teva aplicació

  1. Demana a Didit que activi Authentication per a la teva aplicació. Prova primer en una aplicació sandbox.
  2. Registra les teves URL de redirecció exactes (fins a 50) i els allowed_origins del navegador (fins a 50) que criden l’API d’execució.
  3. Activa els mètodes d’inici de sessió que vulguis oferir. La ID Wallet de Didit està sempre activada.
  4. Tria la configuració de sessió i de contrasenya (vegeu més avall).
  5. Prova el registre, l’inici de sessió, la recuperació de contrasenya, el MFA, la caducitat de la sessió i el tancament de sessió abans de publicar.
Una clau d’accés pertany al seu origen. Si més endavant actives un domini personalitzat, les persones hauran de tornar a registrar les seves claus d’accés.

​
URL de redirecció

Didit només retorna una persona a una adreça que hagis registrat. Registra les teves a la consola, a Authentication > Security and sessions > Redirect URLs and allowed origins. El redirect_uri d’una sol·licitud d’inici de sessió ha de coincidir amb una URL registrada caràcter per caràcter: esquema, amfitrió, port, camí i consulta. Un port diferent, una barra final o una diferència entre majúscules i minúscules constitueix una adreça diferent. Els comodins, els fragments, les credencials a la URL i els esquemes personalitzats es rebutgen. Quan l’adreça no està registrada, Didit mai no hi redirigeix. {origin}/sign-in respon amb 400 i una pàgina que indica què cal registrar i on, i POST {origin}/authorize/ respon amb 400 {"error": "invalid_redirect_uri"}.

​
Desenvolupament en local

Prova a la teva pròpia màquina amb la teva aplicació sandbox:
  1. Registra el teu callback amb el seu port, per exemple http://localhost:3000/auth/callback.
  2. Si el codi del navegador crida l’API d’execució, per exemple per intercanviar el codi a POST {origin}/token/, afegeix també l’origen a Orígens permesos: http://localhost:3000, sense camí i sense barra final.
  3. Inicia el procés d’inici de sessió a l’origen sandbox, https://<slug>.sandbox.auth.didit.me, amb la teva clau pk_test_....
localhost, 127.0.0.1 i [::1] són adreces diferents, i també ho és cada port. Registra cadascuna que utilitzis. Les aplicacions de producció mai no accepten http://. Abans de publicar, registra el teu callback de producció https:// a la teva aplicació de producció.

​
Configuració de l’aplicació

Gestiona aquesta configuració a la consola o amb una sessió de consola autoritzada que tingui write:authentication.

​
Mantén una mateixa persona entre productes

Cada identitat té un valor vendor_data. És el external_id que vas proporcionar quan vas importar la persona o, en cas contrari, l’ID d’identitat de Didit. Apareix al token d’accés, al token d’ID i a GET session/. Utilitza el mateix valor com a vendor_data quan creïs sessions de verificació i enviïs transaccions. Així, els esdeveniments d’autenticació apareixen associats a la mateixa persona a la consola que les seves verificacions i transaccions. Consulta esdeveniments i webhooks. Deriva vendor_data al teu backend a partir d’un token verificat, mai d’un camp del navegador sense comprovar. Utilitza el prompt d’integració compartit per a qualsevol combinació. Llegeix protecció contra bots per conèixer les polítiques que s’executen en iniciar sessió.
Darrera modificació el 7 de novembre del 2026