Què és l'autenticació? Inicis de sessió, sessions i OAuth explicats

L'autenticació és la manera com una aplicació confirma qui és un usuari: normalment comprovant alguna cosa que sap (una contrasenya), alguna cosa que té (un codi enviat al seu telèfon o correu) o una identitat d'un servei de confiança extern (com «Inicia sessió amb Google»). Un cop l'usuari està autenticat, l'aplicació el recorda amb una sessió o un token perquè no hagi d'iniciar sessió a cada pàgina. Decidir què pot fer aquest usuari conegut és un pas diferent, anomenat autorització.

Per què importa quan construeixes amb IA

Afegir un login és una de les peticions més habituals que la gent fa a un constructor d'IA, i una de les més fàcils d'espatllar de manera subtil. Una pàgina de login és simple de generar. La part difícil és tot el que hi ha al voltant:

Les contrasenyes s'emmagatzemen de manera segura?
Cada pàgina privada i cada endpoint de l'API comprova realment qui fa la petició?
Un client connectat pot veure les dades d'un altre canviant un número a la URL?
Què passa quan algú oblida la seva contrasenya?

Una aplicació pot semblar perfectament segura i fallar en totes aquestes preguntes. Entendre les peces mòbils t'ajuda a fer les preguntes adequades i a provar les coses correctes.

Una analogia del dia a dia

Pensa en fer el check-in en un hotel.

A recepció ensenyes el DNI. Això és autenticació: demostrar qui ets. La recepcionista et dona una targeta d'accés. Aquesta targeta és la teva sessió: durant tota l'estada no tornes a ensenyar el DNI; només fas servir la targeta.

La targeta obre la teva habitació, el gimnàs i l'ascensor fins a la teva planta, però no les habitacions d'altres hostes ni l'oficina del personal. Això és autorització: a què pot accedir la teva identitat. Si perds la targeta, l'hotel la pot desactivar a recepció (revocar la sessió). Quan fas el check-out, deixa de funcionar (tancar sessió o caducitat).

«Inicia sessió amb Google» és com si un hotel acceptés una carta d'un soci de confiança que diu «aquesta és la persona», en lloc de comprovar el teu DNI ell mateix.

Mètode	Com funciona	Avantatges	Inconvenients
Correu i contrasenya	L'usuari tria una contrasenya; l'aplicació guarda un hash	Familiar, sense dependències externes	Has d'emmagatzemar bé els hashes i gestionar els restabliments
Enllaç màgic / codi d'un sol ús	L'aplicació envia per correu un enllaç o codi que fa entrar l'usuari	Sense contrasenyes que filtrar o oblidar	Depèn de l'entrega del correu; login més lent
Inici de sessió social (OAuth / OpenID Connect)	L'usuari entra amb Google, Apple, GitHub, etc.	Ràpid per a l'usuari; tu no guardes cap contrasenya	Configuració amb cada proveïdor; usuaris sense aquests comptes
Proveïdor d'autenticació allotjat	Un servei com Clerk, Auth0 o Supabase Auth gestiona el registre, el login i els restabliments	Menys feina de seguretat per a tu	Cost mensual a gran escala; una dependència més
Multifactor (MFA / 2FA)	Una segona comprovació després de la primera, com un codi d'una app d'autenticació	Molt més difícil d'entrar-hi	Una mica més de fricció

Com s'han d'emmagatzemar les contrasenyes

Una aplicació segura mai no guarda la teva contrasenya real. En canvi, guarda un hash: el resultat d'una funció d'un sol sentit que converteix la contrasenya en una cadena fixa. Quan fas login, l'aplicació fa el hash del que has escrit i compara el resultat amb el hash guardat.

Dos detalls fan que això sigui segur:

Una sal: un valor aleatori afegit a cada contrasenya abans del hash, de manera que dues persones amb la mateixa contrasenya obtenen hashes diferents i les taules de cerca precalculades no serveixen de res.
Un algorisme lent pensat per a contrasenyes: com Argon2, bcrypt o scrypt. Els hashes de propòsit general com MD5 o SHA-256 són massa ràpids per si sols; els atacants poden provar milers de milions de conjectures.

El hash no és el mateix que el xifratge. Les dades xifrades es poden desxifrar amb una clau; un hash de contrasenya està dissenyat perquè no sigui reversible de cap manera.

Sessions vs tokens

Després del login, l'aplicació necessita reconèixer-te a cada petició. Hi ha dos enfocaments habituals.

	Sessió (cookie)	Token (p. ex. JWT)
Què guarda el navegador	Un identificador de sessió aleatori en una cookie	Un token signat amb la informació de l'usuari i una data de caducitat
On viu l'estat del login	Al servidor, en una base de dades o un magatzem	Dins del propi token
Tancar la sessió de qualcú a tots els llocs	Fàcil: esborrar la sessió al servidor	Més difícil: el token segueix sent vàlid fins que caduca, tret que mantinguis una llista de bloqueig
Ús típic	Aplicacions web tradicionals	API, aplicacions mòbils, serveis que es parlen entre ells

Per a les cookies, tres configuracions importen: HttpOnly (el JavaScript de la pàgina no pot llegir la cookie), Secure (només s'envia per HTTPS) i SameSite (limita l'enviament en peticions des d'altres llocs). Guardar tokens al localStorage del navegador és habitual, però els exposa a qualsevol script que s'executi a la pàgina.

OAuth i «Inicia sessió amb Google»

OAuth 2.0 és un estàndard per a l'autorització delegada: permet que una aplicació obtingui accés limitat al teu compte d'un altre servei —per exemple, llegir el teu Google Calendar— sense veure mai la teva contrasenya de Google. Et redirigeixen a Google, aprovas permisos concrets (anomenats scopes) i Google dona a l'aplicació un token només per a aquests permisos.

OAuth per si sol va ser dissenyat per concedir accés, no per dir qui ets. OpenID Connect (OIDC) és una capa a sobre d'OAuth 2.0 que afegeix identitat, i és el que fa servir «Inicia sessió amb Google» o «Inicia sessió amb Apple». Per configurar-ho, registres la teva aplicació al proveïdor i obtens un client ID i un client secret; el secret es queda al teu servidor.

Suposem que construeixes un portal on els clients d'una agència de disseny veuen els seus projectes i factures.

Autenticació: els clients entren amb correu i un enllaç màgic, així no cal gestionar contrasenyes. El personal de l'agència entra amb comptes de Google Workspace.
Rols: cada usuari té un rol: client o staff.
Regles d'autorització:

Acció	Client	Personal
Veure els projectes de la seva pròpia empresa	Sí	Sí
Veure els projectes d'altres empreses	No	Sí
Pujar un fitxer a un projecte	Només als seus projectes	Sí
Marcar una factura com a pagada	No	Sí

On s'aplica: al servidor, a cada petició. El servidor busca l'usuari connectat i només retorna els projectes on project.company_id coincideix amb l'empresa de l'usuari. Amagar el botó «Marca com a pagada» no és suficient: l'endpoint ha de rebutjar la petició.

Termes comuns explicats

Terme	Significat
Autenticació (AuthN)	Confirmar qui és algú.
Autorització (AuthZ)	Decidir què pot fer.
Sessió	Que l'aplicació recordi que estàs connectat entre peticions.
Cookie	Una petita dada que el navegador torna a enviar al lloc amb cada petició.
JWT	JSON Web Token: un token compacte i signat que porta dades com l'ID d'usuari i la caducitat.
Rol / permís	Etiquetes com `admin` o `member` que decideixen l'accés.
MFA / 2FA	Exigir una segona prova, com un codi d'una app d'autenticació.
SSO	Inici de sessió únic: un sol login (sovint un compte d'empresa) per a moltes aplicacions.
401 vs 403	«Qui ets?» (no autenticat) vs «No pots fer això» (no autoritzat).

Errors i idees errònies habituals

Comprovar els permisos només a la pàgina. Si el navegador amaga un botó però l'API no ho comprova, qualsevol pot cridar l'API directament.
Confiar en els IDs de la URL. /invoices/1042 ha de comprovar que la factura 1042 pertany a l'usuari connectat.
Inventar la teva pròpia criptografia. Fes servir biblioteques o proveïdors ben coneguts; no deixis que la IA inventi un sistema de hash.
Restabliment de contrasenya feble. Els enllaços de restabliment han de ser d'un sol ús, caducar ràpidament i no revelar si un correu té compte.
Barrejar el teu login amb el del constructor. Els usuaris de la teva aplicació són independents del teu compte a l'eina amb què la construeixes.
Cap límit de freqüència al login. Sense ell, els atacants poden provar contrasenyes sense parar.

Què demanar al teu constructor d'IA

«Afegeix registre i login fent servir [una biblioteca o proveïdor molt conegut]. No escriguis un hash de contrasenyes personalitzat.»
«Guarda les contrasenyes amb hash bcrypt o Argon2.»
«Fes servir cookies HttpOnly i Secure per a la sessió.»
«Afegeix rols: admin i member. Llista cada endpoint i quins rols el poden cridar.»
«Fes que el servidor garanteixi que els usuaris només poden llegir i editar els seus propis registres. Després mostra'm com ho has comprovat.»
«Afegeix restabliment de contrasenya amb enllaços d'un sol ús que caduquin en una hora.»
«Limita la freqüència dels intents de login.»

Després prova-ho tu mateix: crea dos comptes i intenta accedir a les dades d'un d'ells connectat com l'altre. La nostra guia per afegir login i la llista de comprovació de seguretat van més enllà.

Autenticació a Mythex

Mythex no ofereix un producte d'autenticació integrat per als usuaris de la teva aplicació; tu tries un enfocament —correu i contrasenya guardats a la base de dades del projecte, o el SDK d'un proveïdor allotjat— i demanes a l'agent que l'afegeixi. Les claus dels proveïdors van als secrets del projecte, no al xat. Això és independent de com inicies sessió a Mythex mateix. La recepta de la documentació sobre afegir login a la teva aplicació té un prompt inicial que pots adaptar, i què és una API explica on viuen aquestes comprovacions al servidor.

Preguntes

Quina és la diferència entre autenticació i autorització?

L'autenticació comprova qui ets, per exemple verificant la teva contrasenya. L'autorització decideix què pots fer un cop se sap qui ets, com si pots veure la pàgina d'administració o editar la reserva d'algú altre. Les aplicacions necessiten totes dues.

Què és OAuth?

OAuth 2.0 és un estàndard que permet a una aplicació obtenir accés limitat al teu compte d'un altre servei sense veure mai la teva contrasenya. «Inicia sessió amb Google» fa servir OpenID Connect, una capa d'identitat construïda sobre OAuth 2.0, de manera que l'aplicació sap qui ets gràcies a Google.

Ha d'emmagatzemar contrasenyes la meva aplicació?

Mai en forma llegible. Si fas servir inici de sessió amb correu i contrasenya, les contrasenyes s'han d'emmagatzemar com a hashes amb sal, creats amb un algorisme lent dissenyat per a contrasenyes, com Argon2 o bcrypt. Moltes aplicacions eviten el problema fent servir un proveïdor d'autenticació allotjat, inici de sessió amb xarxes socials o enllaços màgics per correu.

Sessions o tokens: quin hauria d'usar la meva aplicació?

Els dos funcionen. Una sessió guarda l'estat del login al servidor i dona al navegador un identificador aleatori en una cookie, que es pot revocar fàcilment. Un token com un JWT porta la informació signada dins d'ell mateix, i és adequat per a API i clients mòbils, però és més difícil de cancel·lar abans que caduqui. Per a una aplicació web típica, les sessions basades en cookies són una opció per defecte sòlida.