Arriba un correu a l'equip de la Botiga Aroma. CataBox, una aplicació de tercers que ajuda els aficionats al cafè a portar un quadern de tastos, vol oferir als seus usuaris que importin automàticament els cafès que han comprat a Aroma. La petició tècnica és simple: «podem llegir les comandes d'un client vostre?».

Amb l'autenticació que vam construir a 03-06 només hi ha una resposta possible, i és dolenta: que el client doni a CataBox el seu correu i la seva contrasenya de la Botiga Aroma, i que CataBox cridi POST /v1/sessions fent-se passar per ell. Això significa que una empresa que no controles desa les contrasenyes dels teus clients, que el token que obté té tots els permisos —inclòs crear comandes i canviar l'adreça d'enviament—, que no li pots revocar l'accés sense obligar el client a canviar la contrasenya, i que no tens manera de saber quines peticions són del client i quines de CataBox.

OAuth 2.0 existeix exactament per a això. Aquesta lliçó explica quin problema resol, com s'articula, quins fluxos es fan servir avui i quins estan desaconsellats, com OpenID Connect hi afegeix a sobre la peça que li falta —la identitat—, i com es valida un token d'un servidor d'autorització extern a la nostra API. En acabar, src/middleware/autenticacio-oauth.js existirà i conviurà amb l'autenticar de 03-06.

Advertiment. OAuth 2.0 és un protocol de seguretat i els seus detalls importen: un paràmetre mal validat converteix un flux correcte en una presa de comptes. El codi d'aquesta lliçó és didàctic i l'ha de revisar un professional de seguretat abans d'un desplegament real. Totes les dades, dominis i credencials són ficticis.

1. El problema: delegar accés sense compartir credencials
2. Els quatre rols d'OAuth 2.0
3. Tokens: accés, refresc i àmbits
4. Tokens opacs enfront de JWT: introspecció o validació local
5. Authorization Code + PKCE
6. Per què el flux implícit i el de contrasenya estan desaconsellats
7. Client Credentials: RàpidEnviaments, màquina a màquina
8. Refresh Token i Device Code
9. state, CSRF i els paràmetres de la petició d'autorització
10. OpenID Connect: la identitat a sobre d'OAuth
11. Validar el token a l'API: JWKS, kid i les claims
12. El middleware autenticarOAuth i la seva convivència amb autenticar
13. Àmbits i rols combinats
14. Registre de clients, secrets i redirect_uri
15. Revocació i tancament de sessió
16. Per què no has d'implementar el teu propi servidor d'autorització
17. Errors d'OAuth i la seva traducció al catàleg d'Aroma

Abans d'OAuth, el patró habitual s'anomenava antipatró de la contrasenya compartida, i es veia així:

La idea central d'OAuth 2.0 cap en una frase: el client mai no veu les credencials; l'usuari s'autentica en un lloc de confiança i el que torna és un permís acotat i revocable.

I una precisió que evita el 90 % de la confusió inicial: OAuth 2.0 és un protocol d'autorització delegada, no d'autenticació. No serveix per a «iniciar sessió amb», per molt que s'utilitzi així a tot arreu. El que serveix per a això és OpenID Connect, que es construeix a sobre (apartat 10).

La conseqüència pràctica més important per a aquest curs: la nostra API és només el servidor de recursos. No mostra pantalles d'inici de sessió, no gestiona contrasenyes, no emet tokens i no sap res de consentiments. La seva única feina a OAuth és:

1. Rebre un Authorization: Bearer <token>.
2. Verificar que aquell token és autèntic, vigent i està adreçat a ella.
3. Extreure qui és el subjecte i quins àmbits té.
4. Decidir si aquella combinació pot fer el que demana.

Això és tot. Res més d'aquesta lliçó no s'implementa dins de la nostra API, i aquesta separació és precisament el valor del protocol.

Fixa't en el pas 5: l'API no pregunta al servidor d'autorització a cada petició. Es descarrega les seves claus públiques una vegada, les desa a la memòria cau i les verifica localment. Per què, a l'apartat 4.

La raó que n'existeixin dos és un compromís entre seguretat i usabilitat: vols que el token que viatja constantment per la xarxa caduqui aviat, però no vols demanar la contrasenya a l'usuari cada quinze minuts. El refresh token viatja poc, es desa millor i es pot revocar de manera centralitzada.

Aquesta arquitectura és la mateixa que ja vam construir a mà a 03-06 amb els nostres propis tokens d'accés i de refresc. La diferència és qui els emet: allà els emetia la nostra API; aquí els emet un servidor d'autorització especialitzat, i la nostra API només els verifica.

Un àmbit és una etiqueta que acota el que un token permet fer. Es demanen a la petició d'autorització, l'usuari els veu a la pantalla de consentiment i viatgen dins del token.

Els de la Botiga Aroma:

Quatre regles de disseny d'àmbits que eviten la majoria dels problemes:

1. Granularitat recurs.accio, no un àmbit per endpoint. Amb 24 URIs, un àmbit per endpoint produeix una pantalla de consentiment illegible.
2. Separar lectura d'escriptura sempre. CataBox demana comandes.llegir i mai comandes.escriure. Aquesta separació és el 80 % del valor.
3. L'àmbit acota, no concedeix. Que un token tingui comandes.llegir no significa que pugui llegir totes les comandes: significa que pot llegir les del subjecte del token. La comprovació de propietat (BOLA, 04-02) continua sent obligatòria.
4. Redactar el text que veurà l'usuari juntament amb l'àmbit. Si no saps explicar-lo en una línia comprensible, l'àmbit està mal dissenyat.

L'access token pot ser de dues naturaleses, i l'elecció afecta directament com el valida la nostra API.

La introspecció (RFC 7662) es veu així:

El camp decisiu és active: si és false, el token no val, sense més explicacions.

Què tria la Botiga Aroma: JWT amb validació local, per tres raons. La latència importa (una crida extra per petició multiplica per dos el temps de resposta del catàleg); la disponibilitat importa (si l'AS cau, amb introspecció cau tota l'API); i la revocació immediata l'aconseguim per una altra via, amb tokens de vida curta (15 minuts) i revocació del refresh token.

El compromís: un access token JWT revocat continua sent vàlid fins que caduqui. Si això és inacceptable per a alguna operació —anul·lar una comanda, canviar la contrasenya—, es fa introspecció només per a aquelles operacions, o es consulta una llista de revocació a Redis. És una decisió per endpoint, no global.

I un recordatori que mai no sobra: un JWT està signat, no xifrat. Qualsevol que intercepti el token en llegeix el contingut amb un descodificador Base64. Mai no fiquis dades sensibles a les claims.

És el flux. Si només en recordes un d'aquesta lliçó, que sigui aquest: serveix per a SPA, per a aplicacions mòbils, per a aplicacions de servidor i per a aplicacions de tercers com CataBox.

PKCE (Proof Key for Code Exchange, es pronuncia «pixy») és l'extensió que el fa segur per a clients que no poden desar un secret. Avui es considera obligatori per a tots els clients, inclosos els confidencials.

Vegem les peticions reals.

Pas 3-4: la petició d'autorització. Passa al navegador de l'usuari, no al servidor de CataBox:

Pas 9: la redirecció de tornada. El codi arriba per la URL, i és d'un sol ús i de vida molt curta (típicament 30–60 segons):

Pas 11: el bescanvi del codi pel token. Això és una petició de servidor a servidor (o des de l'app), mai una redirecció:

El codi d'autorització viatja per la URL del navegador, i això és un canal poc segur: queda a l'historial, pot aparèixer als logs d'un proxy i, al mòbil, una altra aplicació pot registrar el mateix esquema d'URI i robar la redirecció. Abans de PKCE, un atacant que capturés el codi podia bescanviar-lo per un token, perquè l'AS no tenia manera de saber que qui el bescanvia no és qui el va demanar.

PKCE lliga les dues peticions amb un secret d'un sol ús:

La propietat criptogràfica que ho fa funcionar: SHA-256 no es pot invertir. Un atacant que vegi el code_challenge a la URL no pot deduir el code_verifier, així que encara que robi el codi no el pot bescanviar. I code_challenge_method ha de ser sempre S256; el valor plain existeix per compatibilitat i no protegeix de res.

Els trobaràs en tutorials antics. Les millors pràctiques actuals d'OAuth 2.0 (i OAuth 2.1) els retiren.

El cas del flux de contrasenya mereix un matís perquè genera dubtes legítims: es va crear per a aplicacions de primera part, és a dir, teves. Però fins i tot allà és mala idea, perquè la teva pròpia app acaba gestionant contrasenyes, no pot passar per un segon factor i no es beneficia de res de la infraestructura de l'AS. La SPA de la Botiga Aroma i Aroma Mòbil fan servir Authorization Code + PKCE igual que CataBox, encara que siguin nostres. La diferència entre app pròpia i de tercers és que a la pròpia se li pot saltar la pantalla de consentiment, no que faci servir un altre flux.

Quan no hi ha cap usuari implicat, no hi ha a qui demanar consentiment. RàpidEnviaments és un sistema que actua en nom propi per marcar comandes com a enviades.

Tres característiques que el distingeixen:

• No hi ha redirect_uri, ni code, ni consentiment: només el client i el seu secret.
• No hi ha refresh token: quan l'access token caduca, se'n demana un altre. És barat perquè no requereix ningú al davant.
• El sub del token és el mateix client (rapidenviaments), no una persona. A la nostra API això correspon al rol soci, i significa que les comprovacions de propietat per client no s'apliquen: cal autoritzar per una altra via (quines comandes pot tocar RàpidEnviaments i en quins estats).

Un client que fa servir aquest flux és confidencial per definició: desa un secret en un servidor. Mai no es fa servir en una SPA ni en una app mòbil, perquè qualsevol pot extreure el secret del codi descarregat.

La resposta és un access token nou i, a les implementacions modernes, també un refresh token nou. Això s'anomena rotació de refresh tokens i és una defensa important: si un refresh token es fa servir dues vegades, l'AS sap que un dels dos usos és d'un atacant —perquè el legítim ja va rebre el substitut— i revoca tota la família de tokens, tancant la sessió. És la detecció de reutilització, i convé exigir-la en triar proveïdor.

On es desa el refresh token, per tipus de client:

Per a SPA, la recomanació actual és el patró BFF (Backend For Frontend): un petit backend propi desa els tokens i la SPA hi parla mitjançant una galeta de sessió. Si això no és viable, refresh tokens rotatius amb vida curta i mai a localStorage.

Per a dispositius sense teclat ni navegador —una pantalla de la cafeteria que mostra l'estoc, un televisor—. El dispositiu demana un codi, mostra a l'usuari «entra a botigaaroma.example/activar i introdueix KDLF-9XZQ», i mentrestant consulta l'AS fins que l'usuari completa l'autorització al seu mòbil. Es menciona per completesa; no s'aplica als consumidors actuals de la Botiga Aroma.

Quin atac evita state. Sense ell, un atacant inicia el flux amb el seu compte de la Botiga Aroma, captura el code de la redirecció i enganya la víctima perquè el seu navegador visiti https://catabox.example/callback?code=<el de l'atacant>. CataBox bescanvia aquell codi i associa el compte de la Botiga Aroma de l'atacant a la sessió de CataBox de la víctima. A partir d'aquí, tot el que la víctima desi a CataBox va a un compte que l'atacant controla.

La defensa és un valor aleatori lligat a la sessió del navegador:

Amb PKCE ben implementat el risc es redueix molt, però state continua sent obligatori: protegeix d'un atac diferent (la fixació de la sessió del client, no el robatori del codi) i a més serveix per recordar on tornar dins de l'aplicació.

OAuth 2.0 respon a «pot aquesta aplicació fer això?». No respon a «qui és l'usuari?». Fer servir un access token com a prova d'identitat és un error clàssic i perillós: el token no diu res verificable sobre qui el va obtenir ni per a quina aplicació es va emetre, i per això van existir els atacs de substitució de token.

OpenID Connect (OIDC) és una capa fina i estandarditzada sobre OAuth 2.0 que afegeix exactament el que falta.

N'hi ha prou d'afegir openid al scope perquè el flux es converteixi en OIDC:

L'id_token descodificat:

Les claims estàndard més utilitzades:

Dos advertiments que causen bugs reals:

• La clau de l'usuari és sub, mai email. Un correu es pot canviar, es pot reassignar i pot arribar sense verificar. Vincular comptes per correu és una via de presa de compte si email_verified és false.
• L'id_token és per al client, no per a l'API. No s'envia a Authorization: Bearer al servidor de recursos. La nostra API valida l'access token; l'id_token el consumeix CataBox per saber a qui ha connectat.

L'endpoint /userinfo completa el quadre: es crida amb l'access token i retorna les claims de perfil actualitzades. Es fa servir quan l'id_token es va emetre fa temps o quan es prefereix no engreixar-lo.

I el document de descobriment, que evita configurar URL a mà:

D'aquí surt el jwks_uri, que és l'única cosa que la nostra API necessita.

Aquí entra per fi el nostre codi. La mecànica del JWT ja la vam veure a 03-06; el que és nou són dues coses: la signatura és asimètrica (l'AS signa amb la seva clau privada, nosaltres verifiquem amb la seva clau pública) i la clau pública es descobreix dinàmicament mitjançant JWKS.

JWKS (JSON Web Key Set) és un document públic amb les claus de verificació de l'emissor:

Que hi hagi dues claus alhora no és un error: és la rotació. L'AS comença a signar amb aroma-2026-08 mentre els tokens signats amb aroma-2026-05 continuen vigents fins a caducar. La capçalera de cada JWT indica quina cal fer servir:

Això resol de manera nativa el problema de rotació de secrets que vam plantejar a 04-02: no cal redesplegar res, l'API descobreix la clau nova sola.

jose és la biblioteca estàndard de facto per a JOSE/JWT a Node: implementa la memòria cau de JWKS, la rotació i les verificacions de l'estàndard.

Les claims que cal verificar, i què passa si te'n saltes alguna:

aud és la que més s'oblida i una de les més greus. Si un usuari té un token per a una altra aplicació del mateix servidor d'autorització i la teva API no comprova aud, aquell token obre la teva API.

Sobre el rellotge desincronitzat: exp i nbf són instants absoluts. Si el rellotge del teu servidor va trenta segons avançat, rebutjaràs tokens acabats d'emetre amb un token_caducat incomprensible. Per això clockTolerance, i per això els servidors porten NTP. Una tolerància raonable són 30–60 segons; més que això comença a ser un risc.

Sobre la memòria cau de claus: sense ella faries una petició HTTP a l'AS per cada petició entrant, amb la qual cosa hauries perdut l'avantatge de la validació local i hauries creat una dependència dura. Amb ella, l'AS pot estar caigut deu minuts sense que la teva API deixi d'autenticar.

No cal triar de cop. Durant la migració, els dos mecanismes conviuen: els tokens propis de 03-06 (HS256, emesos per la nostra API) i els d'OAuth (RS256, emesos per l'AS). Un middleware selector decideix per la capçalera del token:

El comentari del codi assenyala l'important: la capçalera del token és entrada no fiable. Es fa servir només per decidir quin verificador l'atén; aquell verificador imposa després algorithms: ['RS256'] o ['HS256'] segons correspongui, així que un atacant no hi guanya res mentint a l'alg.

Posició a la cadena. No canvia respecte a 03-06: l'autenticació continua sent el primer dins de cada ruta, no a src/app.js. L'ordre de la cadena de ruta passa a ser:

I src/app.js no es toca en aquesta lliçó: OAuth no afegeix middleware global.

Aquí hi ha una confusió freqüent que convé esvair amb precisió, perquè són dos mecanismes que responen a preguntes diferents:

L'autorització efectiva és la intersecció de les dues. Un token amb ressenyes.moderar el subjecte del qual sigui un client no pot moderar: l'àmbit diu el que l'aplicació va demanar, però el rol diu el que la persona pot. I a l'inrevés: una administradora que fa servir CataBox, que només va demanar comandes.llegir, no pot moderar ressenyes des de CataBox encara que el seu rol l'hi permeti al tauler.

I una regla de compatibilitat per a la convivència: un token propi de 03-06 no porta scope. Perquè exigirAmbit no trenqui les rutes existents, l'autenticarPropi omple ambits amb el conjunt complet que correspon al rol; és a dir, un token de primera part es comporta com si l'usuari hagués consentit tot. És coherent, perquè en aquell flux l'usuari està fent servir directament la nostra aplicació.

Abans que CataBox pugui demanar res, es registra al servidor d'autorització i obté:

Confidencial enfront de públic:

Un error molt repetit: incrustar el client_secret en una SPA o en una app mòbil. Tot el que es descarrega al dispositiu de l'usuari és públic, per molt que estigui ofuscat o compilat. Aquesta és la raó exacta que PKCE existeixi.

La redirect_uri es compara byte a byte. No per prefix, no per comodí, no ignorant el fragment. Un AS que accepti https://catabox.example/* permet que un atacant que controli qualsevol ruta d'aquell domini (una pàgina de perfil amb contingut pujat, per exemple) rebi els codis d'autorització. Regles: HTTPS obligatori, sense comodins, sense paràmetres dinàmics —el que necessitis recordar va a state— i al mòbil, esquemes propis o App Links verificats en comptes d'un esquema que qualsevol app pugui registrar.

Revocació de token (RFC 7009):

Respon 200 fins i tot si el token no existia, deliberadament: així no es pot fer servir l'endpoint per esbrinar si un token és vàlid.

Què revocar i quin efecte té:

Tancament de sessió. Aquí hi ha tres nivells que convé no confondre, perquè l'usuari creu que «tancar sessió» és un de sol:

1. Local: l'aplicació esborra els seus tokens. L'usuari continua amb sessió oberta a l'AS.
2. RP-Initiated Logout (OIDC): l'aplicació redirigeix a end_session_endpoint i l'AS tanca també la seva sessió.
3. Back-Channel Logout: l'AS notifica per darrere a totes les aplicacions connectades perquè tanquin la sessió. És el que cal en un escenari d'inici de sessió únic real.

A la SPA de la Botiga Aroma, «tancar sessió» ha de ser com a mínim el nivell 2; si només fas l'1, prémer «entrar» un altre cop torna a fer entrar l'usuari sense demanar-li res, i en un ordinador compartit això és un problema de seguretat.

Ja ho hauràs intuït llegint la lliçó: implementar un servidor d'autorització OAuth 2.0 correcte és un projecte en si mateix, i fer-ho malament no produeix una fallada visible, produeix una vulnerabilitat silenciosa.

El que cal construir i mantenir correctament:

• Emissió i validació de codis d'un sol ús, amb vida curta i lligats al client.
• PKCE amb S256, comparació exacta de redirect_uri, validació de state i nonce.
• Signatura asimètrica, publicació de JWKS i rotació de claus sense tallar el servei.
• Rotació de refresh tokens amb detecció de reutilització i revocació en cascada.
• Pantalles de consentiment, registre de consentiments i la seva retirada.
• Gestió de contrasenyes, segon factor, recuperació de compte, bloqueig per intents.
• Endpoints de descobriment, introspecció, revocació i userinfo.
• Compliment amb les actualitzacions de l'estàndard i amb els avisos de seguretat.

A més, el teu servidor d'autorització és l'actiu més crític del sistema: qui el compromet, ho compromet tot.

La decisió de la Botiga Aroma: un proveïdor gestionat a auth.botigaaroma.example. La nostra API continua sent únicament servidor de recursos, que és exactament el paper que hem implementat.

I una precisió útil: això no invalida la feina de 03-06. Els tokens propis continuen sent perfectament raonables per al cas de primera part —la teva SPA parlant amb la teva API, sense tercers—. OAuth s'incorpora quan apareix un tercer, quan necessites inici de sessió federat o quan diverses APIs comparteixen identitat.

OAuth defineix els seus propis codis d'error, amb aquesta forma:

Aquest format l'emet el servidor d'autorització, no la nostra API. Els errors que veu un client de CataBox es reparteixen així:

La nostra API manté el seu format propi al cos i fa servir la capçalera WWW-Authenticate per parlar l'idioma d'OAuth, que és el que el RFC 6750 espera:

Així es compleixen les dues coses alhora: la consistència del catàleg cap als nostres consumidors (04-01) i la interoperabilitat amb les biblioteques OAuth genèriques, que llegeixen WWW-Authenticate per decidir si han de refrescar el token o demanar més permisos. No cal ampliar el catàleg d'errors: no_autenticat, token_caducat, permisos_insuficients i servei_no_disponible cobreixen tots els casos que emet el servidor de recursos.

Fer servir l'access token com a prova d'identitat. L'access token és per a l'API; la identitat la dona l'id_token d'OIDC. Confondre'ls obre atacs de substitució de token.

No validar aud. Un token emès per a una altra aplicació del mateix emissor obriria la teva API. És la comprovació més oblidada.

Acceptar qualsevol algorisme. Sense llista blanca, alg:none i la confusió RS/HS són explotables. Fixa ['RS256'].

Desar tokens a localStorage. Qualsevol XSS els roba. Galeta HttpOnly amb un BFF, o el clauer del sistema al mòbil.

Incrustar un client_secret en una SPA o app mòbil. És públic per definició. Client públic + PKCE.

Acceptar redirect_uri amb comodins. Una sola ruta controlable al teu domini es converteix en robatori de codis.

Ometre state perquè «ja fem servir PKCE». Protegeixen d'atacs diferents. Tots dos, sempre.

Demanar tots els àmbits «per si de cas». Baixa la conversió —l'usuari veu una pantalla alarmant— i augmenta el dany d'una bretxa. Demana el mínim i amplia quan calgui.

Consell: comença pel document de descobriment. /.well-known/openid-configuration et dona totes les URL. Configurar token_endpoint a mà és una font d'errors tontos.

Consell: prova la caducitat de debò. Configura un AS de proves amb tokens de 30 segons i comprova que el teu client refresca sol i que la teva API respon token_caducat amb el WWW-Authenticate correcte.

Consell: registra client_id als logs. Saber que una onada de 429 ve de CataBox i no de la teva SPA canvia completament el diagnòstic. Ho veurem a 04-07.

Per a cada consumidor de la Botiga Aroma, indica el flux correcte, el tipus de client i els àmbits mínims. Justifica cada elecció.

1. La SPA de la botiga (https://botigaaroma.example), que permet comprar i ressenyar.
2. L'app Aroma Mòbil, amb les mateixes funcions.
3. El backend de RàpidEnviaments, que marca comandes com a enviades.
4. CataBox, que importa l'historial de compres de l'usuari.
5. Un script intern nocturn que exporta estadístiques de vendes.

Aquest middleware s'ha proposat per validar tokens OAuth. Troba almenys quatre fallades de seguretat i corregeix-les.

La Botiga Aroma permetrà que aplicacions de tercers gestionin la subscripció mensual de cafè d'un client: consultar-la, pausar-la, reprendre-la i canviar la varietat. Dissenya els àmbits necessaris, el text de consentiment de cadascun, i decideix quina combinació de rol i àmbit exigeix cada endpoint.

Solució 1

Justificacions:

• 1 i 2 són públics encara que siguin nostres: el codi es descarrega al dispositiu i no pot desar un secret. I fan servir Authorization Code + PKCE, no el flux de contrasenya, per poder passar per 2FA i no gestionar contrasenyes.
• 3 i 5 no tenen usuari al davant, així que Client Credentials. El sub és la mateixa màquina i no hi ha consentiment.
• 4 és confidencial perquè el bescanvi passa al seu servidor, però fa servir PKCE igualment: la recomanació actual és aplicar-lo sempre. Demana només comandes.llegir; si demanés comandes.escriure caldria rebutjar el registre, perquè no ho necessita per al seu cas d'ús.
• El cas 5 requereix ampliar el catàleg d'àmbits amb vendes.llegir, i convé notar-ho explícitament: els àmbits, com els codis d'error, formen part del contracte i es documenten a openapi.yaml.

Solució 2

Fallades:

1. No valida iss ni aud: accepta tokens de qualsevol emissor i emesos per a qualsevol altra API.
2. No fixa algorithms: vulnerable a alg:none i a la confusió RS/HS.
3. ?? keys[0]: si el kid no coincideix amb cap clau, fa servir la primera «a veure si cola». Un kid desconegut ha de ser un rebuig.
4. Descarrega el JWKS a cada petició: latència afegida, dependència dura de l'AS i un vector de denegació de servei (n'hi ha prou d'enviar tokens amb kid inventats).
5. id: payload.email: l'identificador estable és sub. El correu pot canviar o arribar sense verificar.
6. ambits: payload.scope deixa una cadena on s'espera un conjunt; .has() fallaria o, pitjor, .includes() donaria falsos positius (comandes.llegir «inclou» comandes.lleg).
7. Sense try/catch: si falta la capçalera o el token està mal format, el split o el JSON.parse llancen un TypeError i acaba en un 500 en comptes d'un 401 — i sense WWW-Authenticate.

La correcció és el middleware de l'apartat 12: createRemoteJWKSet amb memòria cau per a 3 i 4, jwtVerify amb issuer, audience i algorithms per a 1 i 2, payload.sub per a 5, un Set per a 6 i el try/catch amb traducció d'errors per a 7.

Solució 3

Àmbits:

Deliberadament no es crea un àmbit per acció (subscripcions.pausar, subscripcions.reprendre…): produiria una pantalla de consentiment illegible i cap d'aquestes accions no té un perfil de risc diferent de les altres. Tampoc no es reutilitza comandes.escriure, perquè una aplicació que gestiona subscripcions no ha de poder crear comandes soltes: barrejar les dues ampliaria el permís més enllà del necessari.

Endpoints:

Dues observacions finals. L'exigirRol('client', ...) no n'hi ha prou per impedir que un client pausi la subscripció d'un altre: això és un BOLA i es comprova al servei, com vam veure a 04-02. I les accions es modelen com a subrecursos substantius (/pausa, /represa) en comptes de verbs, coherentment amb 02-02 i amb els antipatrons de 04-01.

OAuth 2.0 resol un problema molt concret que l'autenticació de 03-06 no podia resoldre: que una aplicació de tercers accedeixi a les dades d'un usuari sense conèixer-ne la contrasenya, amb permisos acotats, caducitat i revocació. Has vist els quatre rols i, sobretot, que la nostra API és només el servidor de recursos: rep un token, el verifica i decideix; res més. Coneixes la diferència entre access token i refresh token, els àmbits dissenyats per a la Botiga Aroma i per què se separa sempre lectura d'escriptura; l'elecció entre token opac amb introspecció i JWT amb validació local, amb el seu compromís explícit sobre la revocació; el flux Authorization Code + PKCE amb el detall de quin atac evita exactament el code_verifier, per què l'implícit i el de contrasenya estan retirats, Client Credentials per a RàpidEnviaments i la rotació de refresh tokens amb detecció de reutilització. Has vist que OpenID Connect és la capa que respon «qui és» amb l'id_token, sub com a clau estable i /userinfo per al perfil. I al projecte ja tens src/config/oauth.js i src/middleware/autenticacio-oauth.js, amb verificació per JWKS i kid —que resol de passada la rotació de claus—, validació completa d'iss, aud, exp, nbf i algorisme, memòria cau de claus, tolerància de rellotge, el nou exigirAmbit i un selector que fa conviure els tokens propis amb els d'OAuth.

Ja saps qui crida i què pot fer. Falta quant pot cridar. A 04-04, Rate limiting i throttling, hi posarem límits: veurem per què tota API pública els necessita —abús, scraping del catàleg, bucles de clients mal programats, cost i equitat—, la diferència entre limitar, estrangular i posar quotes, i els quatre algorismes clàssics amb la seva comparativa, inclòs un cubell de fitxes implementat i comentat. Decidirem què es fa servir com a clau (IP amb el problema de NAT i X-Forwarded-For, client autenticat, client_id d'OAuth) i amb quins nivells per a anònims, clients, RàpidEnviaments i tauler; construirem src/middleware/limit-peticions.js amb express-rate-limit i la seva posició a src/app.js, amb magatzem a Redis per a diverses instàncies; retornarem el 429 amb Retry-After i les capçaleres Aroma-RateLimit-*; i veurem què ha de fer un client ben educat amb el seu retrocés exponencial i el seu jitter.