Il passaggio di attestazioni sull'utente in un token di accesso "abusa" di OpenID Connect?

3

Per prima cosa, ti assicuro che ho letto una serie di post sull'argomento prima di fare questa domanda, ma sono ancora confuso e apprezzerei più approfondimenti.

Quindi, ecco la premessa:

  • Esiste un'applicazione client che autentica l'utente tramite OpenID Connect;
  • Questa applicazione parla con un'API esterna ("server delle risorse") che deve eseguire un'autorizzazione dettagliata in base all'identità dell'utente ;
  • L'API esterna riceve un token di accesso (portante JWT) dall'applicazione client. Il token di accesso viene emesso dal server di autorizzazione nell'ambito di un flusso OpenID Connect;
  • Il token di accesso ha la richiesta del pubblico impostata sull'ID del server delle risorse (e il server delle risorse convalida il reclamo del pubblico);
  • Il token di accesso ha un reclamo UPN / email che descrive l'identità dell'utente.

Ora qui è dove mi confondo:

Da un lato, sto usando OIDC e non semplicemente OAuth 2.0, quindi dovrei essere in regola per quanto riguarda le vulnerabilità della sicurezza (ovviamente a condizione che disponga di misure per mitigare gli attacchi CSRF e per rifiutare i token "falsi").

D'altra parte, però, sto trasmettendo informazioni sull'utente in un token di accesso che si crede sia un grande no-no nel mondo di OIDC & OAuth.

Sto fraintendendo qualcosa? È forse possibile avere informazioni di identità in un token di accesso a condizione che il token di accesso sia stato ottenuto nell'ambito di un flusso OIDC?

Nel caso, mi rendo conto che esiste una nozione di scope, ma non sembrano uno strumento appropriato per definire e gestire le autorizzazioni a grana fine .

    
posta DmytroL 17.05.2018 - 13:17
fonte

0 risposte

Leggi altre domande sui tag