Quindi, credo di capire la logica dietro gli standard di autorizzazione come OAuth. Il token OAuth contiene informazioni sull'utente (nome, ruolo, ecc.), Che posso usare per proteggere la mia applicazione .
Riguarda l'ultima parte della frase precedente che ho una domanda. Diciamo che ho un'app Web con 1000 articoli, come faccio a verificare se un utente specifico (basato sul suo token OAuth) ha accesso a un determinato articolo? Vedo diverse opzioni:
- Conservo tutti gli ID degli articoli che l'utente può vedere nel token OAuth (ad esempio ID1, ID2, ID3, ecc.);
- Al contrario, posso anche memorizzare gli utenti che possono accedere all'articolo (ad esempio, l'articolo 1 può essere letto dagli utenti 1,2,3). Questo è come un ACL;
- Per ogni articolo, memorizzo quali ruoli possono accedere a tale articolo (ad esempio, l'articolo 1 può essere letto per ruolo: lettore). Questo è come RBAC;
- Non proteggere affatto i tuoi contenuti, proprio come sembra che Facebook faccia (sebbene assicurati, ma controllano semplicemente la tua lista di amici prima di darti l'URL diretto alla risorsa).
Per chiarire: non sto cercando una risposta che spieghi che puoi mettere delle affermazioni nel token stesso, in modo da non dover colpire il db per recuperare le tue affermazioni (stateless). Sto cercando modi in cui il back-end dell'applicazione utilizza queste affermazioni per decidere se è concesso o meno l'accesso a un determinato elemento di contenuto.
- L'opzione 1 sembra una cattiva pratica, poiché i token diventeranno infinitamente grandi per i grandi fornitori.
- Se i provider di grandi dimensioni utilizzano l'opzione 2 o 3, avranno una quantità enorme di hit del database (controlla se l'articolo è accessibile all'utente), il che non può essere positivo per le prestazioni. Questo aumento delle prestazioni è uno dei motivi per cui Facebook e Twitters utilizzano un'autorizzazione stateless, anziché un'autorizzazione statutaria. Suppongo che questa penalizzazione delle prestazioni a livello di contenuto sia un ostacolo all'utilizzo delle opzioni 2 o 3.
- Quindi, è l'unica opzione valida per andare con 4?
Un'ultima opzione che vedo è quella di utilizzare l'opzione 3, combinata con il caching pesante. Poiché le autorizzazioni per i contenuti non sono effimere quanto i diritti degli utenti, questa è l'opzione che vorrei fare. Ma è così che i grandi fornitori (Google, Twitter, Dropbox, ecc.) Lo fanno? E come viene implementato praticamente?
Aggiornamento
Qualcuno mi ha parlato di matrice dei permessi di Spring che puoi mettere in memoria, ma non sono sicuro se questa sarebbe la strada da percorrere ..