Risorse · 43
OAuth e OpenID Connect: verifica end-to-end di un'integrazione
Separazione delle autorizzazioni di accesso, delega e dati, quindi test di reindirizzamenti, token, sessioni e revoca.
Aggiornato · 4 min
Obiettivi di questa guida
- Separare l'identità dall'autorizzazione.
- Rifiutare i reindirizzamenti e i token indesiderati.
- Testare i rifiuti con la stessa attenzione riservata ai successi.
- Verificare la rimozione dell'accesso dopo l'uscita o un incidente.
Verifica rapida
- Quali provider ed emittenti sono previsti?
- L'URI di reindirizzamento è registrato correttamente?
- Un token ID viene utilizzato erroneamente come token di accesso?
- Ogni risorsa verifica la proprietà?
- Quali accessi sopravvivono alla revoca?
Metodo passo passo
- 1
Rappresentare graficamente il flusso distribuito.
Identificare il client pubblico o riservato, il browser, il server di autorizzazione, l'API e il provider OIDC. Registrare dove viaggiano i codici e i token, chi li memorizza e quali ruoli sono concessi. Un diagramma di vendita non definisce l'effettiva implementazione. Risultato
Risultato: flusso, limiti di fiducia e proprietari dei componenti.
- 2
Verifica della transazione di accesso.
Utilizza il flusso di codice con PKCE appropriato per il client. Verifica S256, binding della transazione, reindirizzamenti registrati e protezione contro le richieste falsificate. Testa un URI imprevisto, un verificatore errato, codice riprodotto e un emittente imprevisto. RFC 9700 separa i requisiti e le raccomandazioni in base al tipo di client.
Risultato: risultati dei test consentiti e negati.
- 3
Convalida del token corretto.
L'API convalida il proprio token di accesso in base al formato e alle regole del provider: firma o introspezione, emittente, destinatario, scadenza e autorizzazioni. Il client OIDC convalida separatamente il token di identità. Una firma valida non stabilisce che il token appartenga a questa API.
Risultato: contratto di convalida e test di destinatario e scadenza.
- 4
Verifica delle autorizzazioni aziendali
Testa un oggetto di proprietà di un altro account, un ruolo inferiore, un campo privato e un'operazione amministrativa. Un ambito o un gateway autenticato non sostituiscono i controlli lato server sulla risorsa richiesta. Utilizza account e dati di test autorizzati.
Risultato: matrice di ruoli, oggetti, operazioni e negazioni previste.
- 5
Verifica della scadenza e della revoca
Separa la sessione locale, la sessione del provider, il token di accesso e il token di aggiornamento. Testa la disconnessione, lo smarrimento del dispositivo, il cambio di ruolo, la rotazione della chiave di firma e l'interruzione del provider. Documenta il tempo di accesso residuo anziché presumere che la disconnessione revochi immediatamente tutto.
Risultato: cronologia di rimozione dell'accesso ed eccezioni.
- 6
Osservazione senza esporre segreti
Registra il riferimento della transazione, la decisione di convalida, la categoria di errore e la versione della configurazione. Escludi codici, token e segreti. Prepara la diagnosi, l'arresto dell'integrazione e il ripristino a una configurazione convalidata; ripeti i test dopo le modifiche al provider. Risultato atteso
Risultato: procedura operativa e verifiche di regressione.
Esempio pratico fittizio
Situazione illustrativa
Situazione esemplificativa: due client utilizzano lo stesso provider di identità. Un token valido per il primo client viene presentato all'API del secondo client.
Decisione e prove attese
L'API rifiuta il destinatario errato, registra una traccia senza token e non restituisce dati. Il rifiuto diventa un test di regressione.
Distinguere i meccanismi
| Meccanismo | Scopo | Verifica o limitazione |
|---|---|---|
| OAuth 2.0 | Delega l'accesso alle risorse | Permessi oggetto lato server |
| OpenID Connect | Stabilisci l'identità tramite un token ID convalidato | Convalida dell'emittente, del pubblico e della transazione |
| Sessione dell'applicazione | Mantieni l'accesso all'applicazione | Scadenza, invalidazione e protezione della sessione |
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Correggi i rifiuti | Casi proibiti effettivamente bloccati | Correggi ogni accettazione imprevista |
| Ritardo di revoca | Tempo fino alla scomparsa dell'accesso rilevante | Verifica sessioni e token separatamente |
| Errori di convalida | Rifiuti per causa e versione | Separa gli attacchi dagli errori di configurazione |
Errori comuni
- Confondi l'autenticazione con l'autorizzazione
- Accetta qualsiasi pubblico dopo aver verificato la firma
- Registra URI di reindirizzamento generali
- Registrazione dei token per Debug più semplice
Domande frequenti
Il PKCE sostituisce tutti i controlli?
No. Protegge lo scambio di codice nel flusso previsto; la convalida del token, i reindirizzamenti, l'autorizzazione aziendale e le sessioni devono comunque essere verificati.
Un JWT è un permesso?
JWT è un formato. Le attestazioni diventano utilizzabili solo dopo la convalida e l'applicazione delle regole API.
La convalida dovrebbe essere implementata da zero?
È preferibile utilizzare una libreria e una documentazione del provider mantenute, quindi testare la configurazione. Una libreria corretta può comunque essere configurata in modo errato.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
