Com afegir inici de sessió a la teva app: contrasenyes, enllaços màgics, Google i rols

Per afegir inici de sessió a una app, tria un mètode (correu i contrasenya, enllaços màgics -un enllaç d'inici de sessió d'un sol ús enviat per correu-, o «Inicia sessió amb Google») i implementa'l amb una biblioteca d'autenticació provada o un proveïdor allotjat, en lloc de fer-ho des de zero. Després decideix què pot fer cada tipus d'usuari (rols) i aplica-ho al servidor en cada pàgina i en cada petició d'API. Les sessions han d'usar cookies segures, caducar i acabar bé en tancar la sessió.

Aquesta guia repassa cada elecció i els detalls que separen un inici de sessió que funciona d'un que és segur. Per als conceptes que hi ha darrere, consulta què és l'autenticació.

Decideix primer: necessites inici de sessió?

L'inici de sessió afegeix fricció i responsabilitat. El necessites quan:

• Els usuaris tenen dades privades (les seves reserves, documents, factures)
• Els usuaris poden canviar coses que els altres veuran
• Cobres per l'accés
• Diferents persones necessiten permisos diferents (propietari, personal, client)

Potser no el necessites per a un lloc de màrqueting, un directori públic o un formulari que només t'envia un correu. Una llista d'espera no necessita comptes; n'hi ha prou amb un camp de correu electrònic.

Els quatre mètodes d'inici de sessió habituals

Molts apps combinen dos: Inicia sessió amb Google més enllaços màgics per correu és una parella popular que cobreix la majoria de persones sense guardar cap contrasenya.

Correu i contrasenya

Si ofereixes contrasenyes, aquestes són les condicions no negociables:

• Fes el hash de les contrasenyes amb un algorisme de hash lent pensat per a contrasenyes. La guia d'OWASP per emmagatzemar contrasenyes recomana Argon2id, amb scrypt, bcrypt o PBKDF2 com a alternatives. Mai no guardis contrasenyes en text pla ni amb un hash general ràpid.
• Els restabliments de contrasenya usen un enllaç aleatori, d'un sol ús i amb caducitat, enviat al correu verificat.
• No revelis quins correus tenen compte. «Si aquest correu està registrat, hem enviat un enllaç de restabliment» és millor que «No s'ha trobat cap compte».
• Limita la freqüència dels intents d'inici de sessió i de restabliment per frenar l'endevinació de contrasenyes.
• Permet contrasenyes llargues i gestors de contrasenyes; evita les regles que obliguen a combinacions estranyes de caràcters.

Enllaços màgics i codis d'un sol ús

Un enllaç màgic és un enllaç d'inici de sessió enviat per correu a l'usuari. En fer-hi clic, l'usuari inicia sessió. Un codi d'un sol ús és la mateixa idea, però escrit en lloc de clicat.

• Els enllaços i els codis caduquen ràpidament i funcionen només una vegada.
• L'enllaç ha d'iniciar sessió a l'usuari al dispositiu on fa clic, i el token no ha de quedar als registres ni a les eines d'analítica.
• Necessites un enviament de correu fiable; consulta com enviar correus des de la teva app. Prova amb Gmail i Outlook, i revisa les carpetes de correu brossa.

Inicia sessió amb Google (i altres proveïdors OAuth)

«Inicia sessió amb Google» usa OAuth i OpenID Connect: Google confirma qui és l'usuari i diu a la teva app el seu correu i nom. La configuració, a setembre de 2026, es fa a la secció Google Auth Platform de la consola de Google Cloud:

1. Crea o selecciona un projecte i omple la pàgina Branding: el que veuen els usuaris a la pantalla de consentiment (nom de l'app, correu de suport, logotip).
2. A la pàgina Clients, crea un client de tipus «Aplicació web».
3. Afegeix els teus orígens JavaScript autoritzats i els URI de redirecció: les adreces exactes on s'executa la teva app i on Google torna els usuaris després d'iniciar sessió.
4. Guarda l'ID de client i el secret de client als secrets de la teva app.

Coses que solen anar malament, segons la documentació OAuth de Google:

• redirect_uri_mismatch: l'adreça de redirecció ha de coincidir exactament, incloent http contra https, les majúscules i qualsevol barra final. Afegeix-ne una per a la teva adreça de vista prèvia i una per al teu domini en viu.
• Cal HTTPS: els URI de redirecció han d'usar HTTPS, excepte localhost durant el desenvolupament.
• El paràmetre state s'ha de comprovar en tornar, per protegir contra la falsificació de peticions entre llocs. Les bones biblioteques ho fan per tu.

Si només demanes informació bàsica d'inici de sessió (nom, correu, perfil), Google diu que la verificació de l'app no és obligatòria. Demanar accés al Gmail, Drive o Calendar dels usuaris és diferent i requereix verificació.

Construir-ho o usar un proveïdor?

Les dues primeres són raonables. Els proveïdors allotjats gestionen més coses però afegeixen una dependència i de vegades cobren per usuari actiu; consulta els preus actuals a les seves webs. Les biblioteques mantenen tot a la teva base de dades però et deixen més per configurar correctament. Sigui quina sigui l'opció, demana a la IA que l'usi en lloc de crear lògica de contrasenyes o de sessions a mà.

Rols i permisos

L'inici de sessió et diu qui és algú. Els permisos decideixen què pot fer. Mantén-ho simple al principi:

Regles que importen més que els noms dels rols:

• Comprova-ho al servidor, sempre. Amagar un botó a la pàgina no impedeix que algú cridi l'API directament.
• Filtra pel propietari. Un membre que demana la «reserva 123» només ha de rebre-la si és seva.
• Els usuaris no es poden promocionar a si mateixos. Ignora els camps de rol enviats des del navegador en actualitzar el perfil.
• Per defecte, sense accés. Les noves rutes han de requerir inici de sessió tret que decideixis el contrari.

Prova-ho amb dos comptes: entra amb un, anota l'ID d'un registre, després entra amb l'altre i intenta obrir-lo. La nostra llista de seguretat té la prova completa.

Seguretat de les sessions

Després de l'inici de sessió, l'app recorda l'usuari amb una sessió, normalment una cookie. La guia d'OWASP sobre gestió de sessions recomana:

• Cookies de sessió establertes amb Secure (només HTTPS), HttpOnly (il·legibles per als scripts de la pàgina) i SameSite
• Un nou ID de sessió emès en iniciar sessió, i de nou quan canviïn els privilegis
• Un temps d'inactivitat i una durada màxima absoluta, aplicats al servidor
• Tancar sessió que acabi la sessió al servidor, no només que esborri la cookie
• Sessions invalidades quan un usuari canvia la contrasenya

Guardar els tokens d'inici de sessió al localStorage del navegador és habitual en tutorials, però els exposa a qualsevol script que s'executi a la pàgina; les cookies segures solen ser el millor valor per defecte per a les apps web.

Un prompt que cobreix l'essencial

Afegeix comptes d'usuari a aquesta app. Els usuaris es poden registrar i iniciar sessió amb correu i contrasenya, o amb Google. Usa [biblioteca o proveïdor] en lloc de codi d'autenticació propi. Fes el hash de les contrasenyes amb Argon2id o bcrypt. Afegeix el restabliment de contrasenya per correu amb un enllaç d'un sol ús que caduqui en una hora. Guarda les sessions en cookies segures i HttpOnly. Protegeix /dashboard i cada ruta /api perquè només els usuaris connectats les puguin usar, i assegura't que els usuaris només vegin els seus propis projectes. Afegeix un rol «admin» que pugui veure tots els usuaris; només els administradors poden accedir a /admin, comprovat al servidor.

Despràs, prova-ho: registra't, tanca sessió, inicia-la de nou, restableix la contrasenya, intenta obrir una URL privada sense sessió iniciada i intenta obrir el registre d'un altre usuari.

Errors habituals en l'inici de sessió creat amb IA

• Protecció només a la pàgina. La pàgina redirigeix els usuaris no connectats, però l'API retorna dades a qualsevol.
• Secrets al navegador. Els secrets de client OAuth i les claus d'administració del proveïdor d'autenticació pertanyen al servidor.
• URL de vista prèvia i en viu confoses. El URI de redirecció de Google o l'enllaç de restabliment per correu apunta a la vista prèvia, així que l'inici de sessió es trenca després de publicar.
• Sense verificació del correu. Qualsevol pot registrar-se com a qualsevol@empresa.com. Verifica el correu abans d'atorgar res lligat a aquella adreça.
• Provar només el camí feliç. Prova contrasenyes incorrectes, enllaços caducats i un segon compte.

Afegir inici de sessió a Mythex

A Mythex, l'inici de sessió per als usuaris de la teva app és quelcom que afegeixes a la teva app; és independent del teu propi compte de Mythex. Mythex no ofereix un producte d'autenticació integrat, així que portes una biblioteca o un proveïdor d'autenticació i les seves claus:

1. Tria un enfocament, per exemple correu i contrasenya guardats a la teva pròpia base de dades, o l'SDK d'un proveïdor allotjat.
2. Si guardes els usuaris tu mateix, l'app necessita una base de dades; demana-la al xat o usa /database.
3. Posa les claus del proveïdor als secrets del projecte (/secrets o la configuració del projecte).
4. Usa un prompt com el de dalt i prova-ho a la Vista prèvia. Per a Inicia sessió amb Google, afegeix URI de redirecció tant per a la vista prèvia com per a l'adreça publicada.

Consulta Afegir inici de sessió a la teva app a la documentació. Si estàs construint un producte de pagament, com construir un MVP de SaaS cobreix comptes i facturació junts.

Preguntes