Què és OAuth? « Inicia sessió amb Google » i l'accés delegat explicats

OAuth és un estàndard obert que permet a un usuari donar a una app un accés limitat al seu compte en un altre servei sense lliurar-li la contrasenya. Quan fas clic a « Connecta Google Calendar » i veus una pantalla que pregunta « Vols permetre que aquesta app vegi els teus esdeveniments? », això és OAuth. L'app rep un token només per a allò que has aprovat, que pots revocar en qualsevol moment. La mateixa maquinària, amb una capa addicional anomenada OpenID Connect, és la que fa funcionar « Inicia sessió amb Google » i botons similars.

Per què OAuth importa quan construeixes amb IA

OAuth apareix en dues situacions habituals quan construeixes una app:

1. Inici de sessió social. Vols que els teus usuaris puguin « Iniciar sessió amb Google » (o Apple, Microsoft, GitHub) en lloc de crear una altra contrasenya. Consulta com afegir inici de sessió a la teva app.
2. Connectar-se als comptes dels usuaris en altres serveis. La teva app necessita llegir el calendari d'un usuari, publicar al seu compte de xarxes socials, obtenir fitxers del seu núvol o sincronitzar les seves dades comptables.

En tots dos casos, el teu constructor d'IA pot escriure el codi, però alguns passos només els pots fer tu: crear una app de desenvolupador amb el proveïdor, obtenir un client ID i un client secret, registrar les URL de callback i, per a alguns permisos, superar la revisió del proveïdor. Entendre com funciona OAuth fa que aquests passos —i els errors que produeixen— siguin molt menys misteriosos. Per a la visió general de l'inici de sessió, consulta què és l'autenticació.

Una analogia quotidiana

Pensa en una targeta d'accés d'un hotel. Al fer el check-in, la recepció confirma qui ets i després et dona una targeta que obre la teva habitació i el gimnàs —no les altres habitacions, ni les zones del personal— i deixa de funcionar al check-out. La targeta no conté el teu passaport. Si la perds, la recepció la cancel·la i en emet una de nova.

• La recepció és el servidor d'autorització (la pàgina d'inici de sessió de Google).
• La comprovació de la teva identitat és iniciar sessió a Google.
• La targeta d'accés és el token d'accés.
• « Només habitació i gimnàs » són els àmbits que vas aprovar.
• El check-out és quan el token caduca, o quan revoques l'accés.

L'app que fas servir mai no veu la teva contrasenya de Google, només la targeta d'accés.

Com funciona OAuth, pas a pas

El flux més habitual per a apps web és el flux de codi d'autorització. Això és el que passa quan un usuari connecta el seu Google Calendar a una app de cites:

1. Clic. L'usuari fa clic a « Connecta Google Calendar ».
2. Redirecció al proveïdor. L'app envia el navegador a Google amb el seu client ID, els àmbits que vol (llegir esdeveniments del calendari) i el redirect URI on Google ha de tornar l'usuari.
3. Inici de sessió i consentiment. L'usuari inicia sessió a Google (si encara no ho ha fet) i veu una pantalla de consentiment amb el que l'app demana. Fa clic a Permetre.
4. Tornada amb un codi. Google redirigeix el navegador al redirect URI de l'app amb un codi d'autorització d'un sol ús i de vida curta.
5. Intercanvi al servidor. El servidor de l'app envia aquest codi, juntament amb el seu client secret, directament a Google i rep un token d'accés (i sovint un refresh token).
6. Ús de l'API. El servidor crida l'API de Google Calendar amb el token d'accés i obté els esdeveniments de l'usuari.

El callback del pas 4 té un aspecte semblant a aquest:

https://lateva-app.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

I la resposta del token del pas 5 és JSON com:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

El punt de disseny important: l'intercanvi del token es fa servidor a servidor, de manera que el client secret i els tokens mai no han de passar pel navegador.

OAuth vs OpenID Connect vs el teu propi inici de sessió

Molta apps combinen tots dos: inici de sessió amb correu i contrasenya, més « Inicia sessió amb Google » via OIDC, més connexions OAuth separades amb altres serveis.

Termes clau

Idees errònies habituals

• « OAuth és un sistema d'inici de sessió.» OAuth simple concedeix accés; OpenID Connect gestiona la identitat. Fer servir un token d'accés pur com a prova de qui és algú ha causat errors de seguretat reals.
• « L'app obté la meva contrasenya.» Mai no ho fa. Aquest és precisament el punt.
• « Demanar més àmbits no fa mal.» Els usuaris desconfien de les peticions amplies, i proveïdors com Google poden exigir una revisió de l'app per a àmbits sensibles o restringits. Demana només el que necessitis.
• « El client secret pot anar al frontend.» Qualsevol cosa al codi del navegador és pública. Guarda'l als secrets del servidor.
• « Si funciona en proves, funcionarà en producció.» Els proveïdors sovint limiten les apps no verificades —per exemple, a usuaris de prova indicats— i la redirect URI del domini en directe s'ha de registrar per separat.
• « Els tokens duren per sempre.» Els tokens d'accés caduquen ràpidament, i els usuaris poden revocar l'accés. La teva app ha de gestionar tots dos casos amb elegància.

Què demanar al teu constructor d'IA

• « Afegeix « Inicia sessió amb Google » fent servir OpenID Connect amb una biblioteca d'autenticació ben mantinguda; no escriguis el flux d'OAuth a mà. »
• « Fes servir el flux de codi d'autorització amb PKCE i comprova el paràmetre state. »
• « Llegeix el client ID i el client secret de les variables d'entorn al servidor. »
• « Demana només els àmbits que necessitem: accés de només lectura al calendari. »
• « Digues-me totes les URL de redirecció que he de registrar a la consola del proveïdor, per a la previsualització, la URL publicada i el meu domini personalitzat. »
• « Guarda els refresh tokens xifrats a la base de dades, i gestiona els tokens caducats o revocats demanant a l'usuari que es torni a connectar. »
• « Deixa que els usuaris desconnectin la integració des de la seva pàgina de configuració. »

OAuth i Mythex

Mythex no té inici de sessió integrat per als usuaris finals de les apps que construeixes; la seva documentació descriu un enfocament de portar el teu propi proveïdor: tries una biblioteca d'autenticació o un proveïdor allotjat, guardes les seves claus com a secrets del projecte i l'agent escriu el codi. La recepta per afegir autenticació té un prompt inicial per a això. També trobaràs OAuth dins de Mythex: pots registrar-te amb Google, connectar GitHub per a la sincronització de repositoris fa servir OAuth de GitHub, i els clients d'IA que es connecten a Mythex via MCP passen per una pàgina de consentiment OAuth. Per a més informació, consulta què és l'autenticació i què és l'autenticació de dos factors.

Preguntes