Sono sull'orlo della creazione di un servizio all'interno del nostro server delle risorse che scambia un token di accesso generato esternamente per un token di accesso generato internamente. Tuttavia, questo sembra sbagliato. Non ho trovato prove che qualcun altro abbia bisogno di questo modello, il che è un buon segno che mi manca qualcosa.
Dettagli
Stiamo eseguendo un tipico SOA basato su REST. Deleghiamo l'autenticazione a Auth0 in modo da poter supportare i clienti con diversi provider di identità. Allo stesso modo, riceviamo richieste API ed eseguiamo l'autenticazione in base al token di accesso generato da Auth0. Tuttavia, vogliamo gestire internamente le autorizzazioni dettagliate dell'API e vogliamo un maggiore controllo sul ciclo di vita del token (ad esempio, revoca forzata del lato server).
Auth0 supporta le richieste personalizzate, ma ciò richiederebbe un accoppiamento molto stretto tra il nostro server e il loro (o le nostre regole nel loro server). Inoltre, ciò non risolve neanche la necessità di revoca forzata.
È che sembra che questa esigenza può essere soddisfatta scambiando il token di accesso generato da Auth0 per un nuovo token di accesso generato dal nostro server, che potrebbe iniettare attestazioni sulle autorizzazioni configurate dell'utente / identità. Questo ci permetterebbe di controllare, bene tutto ciò che vogliamo sul token, incluso revocarlo.
Preoccupazioni
Continuo a setacciare le specifiche OIDC e OAuth2 e a cercare altri con esigenze simili. La mancanza di colpi mi ha preoccupato.
Esiste un modo migliore per gestire l'autorizzazione internamente, pur delegando l'autenticazione a un provider come Auth0?
Esiste un modo migliore per supportare la revoca del token rispetto alla generazione e al monitoraggio dei token stessi? È possibile mantenere i token stateless e supportare la revoca allo stesso tempo? (Se questo è troppo per un post SE, quindi ignorare questa parte.)
Aggiornamento!
Ho scoperto Token Exchange che sembra quello che sto cercando ... una versione basata su OIDC / OAuth2 di un Secure Token Service in grado di scambiare token da un lato di un ambiente eterogeneo federato per token gestiti da un altro lato dell'ambiente.
Quindi, perfezionerò la mia domanda: in base al caso d'uso che ho descritto, il modello di Token Exchange è appropriato? Se no, cosa?