Saltar al contingut principal
L’autenticació és nova. La pàgina d’inici de sessió allotjada executa tots els mètodes d’aquesta pàgina. Els endpoints JSON que hi apareixen són per a equips que creen les seves pròpies pantalles d’inici de sessió (sign_in_ui: "own").
Activa un mètode amb PUT methods/{name}/ i {"enabled": true} a l’API de gestió de l’autenticació de la teva aplicació, o des de la consola. L’inici de sessió allotjat només mostra els mètodes que hagis activat. Cada crida JSON següent comença amb una transaction obtinguda de POST authorize/. Aquesta transacció dura 10 minuts. Un inici de sessió correcte retorna {code, redirect_uri, state}. Intercanvia el codi a POST token/ en un termini de 60 segons (consulta tokens i JWKS). En lloc d’un codi, una crida d’inici de sessió pot retornar un d’aquests passos. Completa el pas i després rebràs el codi.

​
Contrasenya

POST password/ rep transaction, email i password.
  • Una contrasenya ha de complir el teu password_min_length (8, 10, 12 o 14 caràcters; 10 per defecte). Les contrasenyes comunes i les formades només per números es rebutgen amb password_policy. Quan la comprovació de contrasenyes filtrades està activada, una contrasenya filtrada coneguda es rebutja amb password_breached.
  • Només les persones amb un correu electrònic verificat poden iniciar sessió amb contrasenya.
  • Una contrasenya incorrecta, un correu electrònic desconegut, un correu electrònic no verificat, un compte bloquejat i un compte inhabilitat reben la mateixa resposta: 400 {"error": "invalid_credentials"}. La teva interfície no pot saber quin va ser el motiu, i tampoc no ho pot saber un atacant.

​
Registre

El registre verifica primer el correu electrònic. Crida POST email/start/ amb purpose: "signup", email i password, i després POST email/complete/ amb el codi. El compte es crea amb un correu electrònic verificat.
  • signup_policy decideix qui es pot registrar: anyone, invited (només amb un enllaç d’invitació) o allowed_domains.
  • Amb allow_subaddresses: false (el valor per defecte), es rebutja una adreça amb + a la part local.
  • Quan la teva marca defineix enllaços a les condicions o a la política de privacitat, el formulari de registre allotjat demana a la persona que els accepti.

​
Codi per correu electrònic

POST email/start/ rep transaction, purpose (login o signup) i email, i retorna 202 {challenge, expires_in: 600}. La persona rep un codi de 6 dígits que dura 10 minuts. POST email/complete/ rep transaction, purpose, challenge i code. Tens 5 intents; després, la persona ha de sol·licitar un codi nou. La pàgina allotjada ofereix un codi nou després de 30 segons. Un codi d’inici de sessió per a una adreça sense compte en crea un si la teva signup_policy ho permet. Això és el registre sense contrasenya.

​
Enllaç màgic

La pàgina allotjada envia un enllaç d’inici de sessió que dura 15 minuts. Queda vinculat a la transacció PKCE original, de manera que l’enllaç només funciona en el flux que l’ha iniciat. La persona confirma l’inici de sessió a la pàgina que obre l’enllaç. No hi ha cap endpoint JSON per als enllaços màgics.

​
Codi per telèfon

POST phone/start/ rep transaction, phone i un channel opcional (sms, el valor per defecte, o whatsapp). El número es normalitza a E.164. Retorna 202 {challenge, expires_in: 600}. POST phone/complete/ rep transaction, challenge i el code de 6 dígits. Tens 5 intents.
  • Els codis de telèfon s’envien mitjançant la verificació de telèfon de Didit. Activa el mètode amb el workflow_id d’un flux de treball que contingui la verificació de telèfon.
  • Un primer inici de sessió amb telèfon només crea un compte quan signup_policy és anyone.
  • Si l’enviament falla, la crida retorna 503 {"error": "delivery_unavailable"}.

​
Claus d’accés

Les claus d’accés fan servir WebAuthn. La part confiant és l’origen d’inici de sessió de la teva aplicació. Didit demana una credencial descobrible (clau resident) i sempre exigeix verificació de l’usuari, com una empremta digital, la cara o el PIN del dispositiu. Didit no demana atestació.
  • Un repte de clau d’accés dura 5 minuts.
  • Afegir una clau d’accés requereix una sessió creada en els últims 5 minuts. En cas contrari, la crida retorna 403 {"error": "reauthentication_required"}. Primer torna a iniciar la sessió de la persona.
  • Un inici de sessió amb clau d’accés compta com a multifactor.
  • Després del registre, la pàgina allotjada ofereix afegir una clau d’accés (passkeys/setup/begin/ i passkeys/setup/complete/).
  • Les aplicacions d’Android registrades a l’aplicació poden fer servir les mateixes claus d’accés.

​
Inici de sessió social

Google, Microsoft, Apple i GitHub utilitzen les teves pròpies credencials d’aplicació OAuth, que s’estableixen amb PUT methods/{provider}/ i credentials: {client_id, client_secret}. La URL de callback del proveïdor està a l’origen del teu inici de sessió. La primera vegada que algú inicia sessió amb un proveïdor, també demostra que és propietari de l’adreça de correu electrònic amb un codi (POST social/email/start/ i POST social/email/verify/). Els inicis de sessió posteriors amb aquest proveïdor ometen aquest pas. GitHub no pot demostrar un inici de sessió recent, de manera que no s’ofereix quan envies prompt=login o max_age.

​
SSO d’organització

L’SSO d’organització permet que l’empresa d’un client iniciï sessió a través del seu propi proveïdor d’identitat SAML o OIDC. Configura’l per a cada organització del client a organizations/{id}/sso/ amb protocol (saml o oidc), enabled i config.
  • Pots enviar a l’equip de TI del client un enllaç de configuració que té una validesa de 7 dies.
  • Les metadades del teu proveïdor de servei SAML es publiquen a {origin}/sso/saml/metadata/.
  • L’inici de sessió allotjat troba la connexió a partir del domini de correu electrònic verificat de la persona, o a partir de organization=<slug> a la URL d’inici de sessió.

​
Didit ID Wallet

Les persones que ja s’han verificat amb Didit poden iniciar sessió amb el seu Didit ID Wallet. Aquest mètode sempre està activat. Aleshores, el verified_identity de la sessió conté el que la persona ha decidit compartir.

​
MFA

El segon factor és una aplicació d’autenticació (TOTP) amb codis de recuperació, o una clau d’accés.
  • mfa_policy decideix qui ha d’utilitzar MFA: optional, everyone o organization_admins (el valor per defecte). Qui hagi registrat un autenticador ha de fer-lo servir sempre.
  • Per registrar un autenticador, crida POST mfa/enroll/ amb una sessió recent (creada fa menys de 5 minuts). Retorna {challenge, uri}; mostra el uri com a codi QR. A continuació, envia el primer codi a POST mfa/confirm/. La resposta conté 10 codis de recuperació d’un sol ús. Mostra’ls una sola vegada.
  • En iniciar sessió, envia un codi TOTP o de recuperació a POST mfa/complete/ amb el challenge. Tens 5 intents. Per utilitzar una clau d’accés, crida POST mfa/passkey/begin/ i POST mfa/passkey/complete/.
  • Els codis utilitzen intervals de 30 segons. Un codi que ja s’ha acceptat no es pot tornar a utilitzar.
  • Els codis SMS i de correu electrònic no estan disponibles com a segon factor.

​
Oblidar i restablir la contrasenya

POST password-reset/start/ rep email i retorna 202 {"status": "sent", "expires_in": 1800}. La resposta és la mateixa tant si l’adreça està associada a un compte com si no. L’enllaç de restabliment té una validesa de 30 minuts. POST password-reset/complete/ rep token i password i retorna {"status": "password_changed"}. A més:
  • esborra un bloqueig,
  • finalitza totes les sessions quan revoke_on_password_change està activat (el valor per defecte),
  • invalida els altres codis i enllaços pendents d’aquesta persona.

​
Invitacions

Amb signup_policy: "invited", només les persones convidades es poden registrar. Un enllaç d’invitació té una validesa de 7 dies i obre la pàgina allotjada /invite. Continua amb tokens i JWKS, o llegeix protecció contra bots per als bloquejos i els desafiaments.
Darrera modificació el 7 de novembre del 2026