In OpenId Connect, perché non vengono richieste richieste incluse nel token di identificazione?

3

Nel flusso OpenId Connect Implict, dopo che il server di autorizzazione ha autenticato l'utente e l'utente ha concesso al client l'accesso alle richieste richieste, un token ID viene restituito al client.

Questo token di identificazione contiene reclami sull'autenticazione di un utente finale da parte di un server di autorizzazione . Queste affermazioni consistono in una serie di richieste richieste, alcune facoltative e "Può contenere altri reclami".

In un secondo momento, il client può consegnare il token di accesso a un'API, che a sua volta può recuperare richieste di informazioni dall'endpoint UserInfo.

Qual è la ragione per cui le attestazioni restituite dall'endpoint UserInfo non vengono restituite direttamente al client dopo che l'utente è stato autorizzato, come parte del token di identificazione? Perché è necessario l'endpoint UserInfo? Se le attestazioni sono state restituite come parte del token Id, non sarebbero necessarie ulteriori richieste.

È perché il token ID potrebbe contenere dati che non si desidera condividere con l'API, ad esempio un token di aggiornamento?

    
posta Nitramk 15.06.2015 - 17:52
fonte

1 risposta

1

Considera che il punto del server di autorizzazione è semplicemente decidere se dovresti essere autorizzato a fare qualcosa. Il punto dell'endpoint delle informazioni dell'utente è fornire informazioni su chi sei. Il fatto che il di autorizzazione possa fornire queste informazioni a te non significa che dovrebbe .

In alcuni casi il server delle autorizzazioni potrebbe non sapere chi sei oltre le credenziali, quindi rimanda a un altro server per fornire ulteriori informazioni.

    
risposta data 31.07.2015 - 19:48
fonte

Leggi altre domande sui tag