Supporto Single Sign-On per API REST

Question

Sto cercando di trovare il modo migliore per risolvere il seguente problema: la nostra applicazione è SaaS e supporta SAML per l'accesso al Web. L'applicazione espone anche le API REST che dovrebbero essere utilizzate nei processi automatici e non presidiati, il che significa che non esiste un utente interattivo per digitare le credenziali. Dobbiamo consentire agli sviluppatori di autenticare a livello di codice il processo automatico contro l'IdP pertinente (che è già definito, perché le stesse credenziali utilizzate per l'accesso API possono anche essere utilizzate per accedere all'applicazione web).

Il flusso che immagino è il seguente: il programma si autentica utilizzando un'API dedicata, ottiene un token e utilizza il token per le chiamate successive.

La maggior parte delle risposte che trovo quando si cercano i modi migliori per proteggere le API REST suggeriscono oAuth, che normalmente richiede un utente interattivo, perché discutono un'applicazione interattiva che tenta di accedere alle API REST in altri sistemi per conto dell'utente, è lì per digitare la password. OAuth è anche la risposta alla mia sfida? Se sì, qual è il flusso?

Grazie!

Answer 1

OAuth 2.0 può essere utilizzato per questo caso d'uso perché consente ai cosiddetti clienti (ovvero i processi non presidiati) di ottenere un token di accesso concesso dagli sviluppatori e utilizzare tale token contro le API.

Un flusso tipico da utilizzare qui è il flusso codice: si esegue un server di autorizzazione che emette token ai client se consentito dagli sviluppatori. Gli sviluppatori accedevano al server di autorizzazione tramite SAMO Web SSO.

Si noti che non richiede un utente attivo al momento dell'accesso all'API REST, ma ne richiederebbe uno al momento dell'emissione del token. Credo che sia quello che stai effettivamente cercando. In caso contrario, ci sono altri flussi che possono essere sfruttati che non richiedono affatto un utente attivo, ma credo che non siano adatti per questo particolare caso d'uso; dopotutto vuoi che i clienti operino per conto degli sviluppatori.

tuo Autorizzazione Server può anche emettere un token di aggiornamento al cliente oltre ad un token di accesso in modo che alla scadenza del vecchio token di accesso, il cliente può ottenere un nuovo token di accesso dal server di autorizzazione utilizzando il Aggiorna token, senza dover ricorrere (in modo interattivo) allo sviluppatore.