Sembra che tu possa beneficiare di un server di autorizzazione separato su cui tutte le tue applicazioni possono fare affidamento.
A lungo termine sarà probabilmente più facile rendere autenticazione / autorizzazione una preoccupazione trasversale invece di copiare utenti da su richiesta a un altro.
OpenId Connect potrebbe essere appropriato; si basa su OAuth2 .
Questi potrebbero non essere i difetti che stai cercando, ma prendi in considerazione queste situazioni separate:
- 3 nuovi sistemi C, D ed E vengono introdotti nell'organizzazione e gli utenti devono accedere a tutti loro
- Si presenta un nuovo requisito per System B per chiamare un'API HTTP, System F, come utente corrente
- Un utente viene rimosso dal sistema A
- Il sistema A è scomposto, ma il sistema B è diventato fondamentale per l'azienda
- Un utente apre B direttamente, senza passare da A
- La rigenerazione di tutte le chiavi segrete potrebbe causare un carico non necessario sulla rete / sui sistemi
- La società di consulenza che sviluppa System B deve apprendere il metodo di autenticazione personalizzato
- I nuovi membri del team devono imparare il tuo protocollo di autenticazione nazionale invece di uno standard di settore
- Avendo ottenuto l'accesso al Sistema A, un utente malintenzionato ha anche accesso al Sistema B.
Quello che hai descritto non suona come l'autenticazione basata su token IMO. Nell'autenticazione basata su token, il nome utente e la password vengono scambiati per un token, che verrebbe presentato al sistema A ad ogni richiesta.
Ad un livello elevato, questo è il modo in cui ho capito che l'autenticazione basata su token funziona:
- L'utente non autenticato naviga nel sistema A
- Il sistema A reindirizza il browser degli utenti a System Z, il provider di autenticazione
- L'utente inserisce le sue credenziali in Sistema Z
- System Z reindirizza il browser dell'utente al Sistema A, con un token
- Tutte le richieste successive dal browser dell'utente al sistema A includono il token
- Il sistema A si fida dei token emessi dal Sistema Z
Si noti che l'utente non inserisce le proprie credenziali nel sistema A.
I passaggi precedenti sono troppo semplificati; non includono la scadenza dei token o i token di aggiornamento. Ho descritto il più semplice flusso di autorizzazione OAuth2 (flusso implicito); il più comune è il "Flusso del codice di autorizzazione".
Il flusso implicito è adatto ai client JavaScript, mentre il flusso del codice di autorizzazione è adatto alle applicazioni basate su server.
Ci sono molte buone informazioni online su OAuth2 e OpenID Connect.