Condividi tramite

OAuth 2.0 e OpenID Connect (OIDC) in Microsoft Identity Platform

  • Articolo

La conoscenza di OAuth o OpenID Connect (OIDC) a livello di protocollo non è necessaria per usare Microsoft Identity Platform. Tuttavia, si incontreranno termini e concetti del protocollo quando si usa Identity Platform per aggiungere l'autenticazione alle app. Mentre si lavora con l'Interfaccia di amministrazione di Microsoft Entra, la documentazione e le librerie di autenticazione, conoscere alcuni concetti fondamentali può aiutare l'integrazione e l'esperienza complessiva.

Ruoli in OAuth 2.0

Quattro parti sono in genere coinvolte in uno scambio di autenticazione e autorizzazione OAuth 2.0 e OpenID Connect. Questi scambi vengono spesso chiamati flussi di autenticazione o flussi di aut.

Diagramma che mostra i ruoli di OAuth 2.0

  • Server di autorizzazione: Microsoft Identity Platform è il server di autorizzazione. Detto anche provider di identità o IdP, gestisce in modo sicuro le informazioni dell'utente finale, il relativo accesso e le relazioni di attendibilità tra le parti nel flusso di autenticazione. Il server di autorizzazione rilascia i token di sicurezza usati dalle app e dalle API per concedere, negare o revocare l'accesso alle risorse (autorizzazione) dopo che l'utente ha eseguito l'accesso (autenticato).

  • Client: il client in uno scambio OAuth è l'applicazione che richiede l'accesso a una risorsa protetta. Il client può essere un'app Web in esecuzione in un server, un'app Web a pagina singola in esecuzione nel Web browser di un utente o un'API Web che chiama un'altra API Web. Spesso il client viene denominato applicazione client, applicazione o app.

  • Proprietario della risorsa: il proprietario della risorsa in un flusso di autenticazione è in genere l'utente dell'applicazione o utente finale nella terminologia OAuth. L'utente finale "è proprietario" della risorsa protetta (e dei relativi dati) a cui l'app accede per suo conto. I proprietari delle risorse possono concedere o negare all'app (il client) l'accesso alle risorse di cui sono proprietari. Ad esempio, l'app potrebbe chiamare l'API di un sistema esterno per ottenere l'indirizzo di posta elettronica di un utente dal proprio profilo nel sistema. I dati del profilo sono una risorsa di proprietà dell'utente finale nel sistema esterno e l'utente finale può fornire il consenso o negare la richiesta dell'app di accedere ai dati.

  • Server di risorse: il server di risorse ospita o fornisce l'accesso ai dati di un proprietario della risorsa. Nella maggior parte dei casi, il server di risorse è un'API Web che precede un archivio dati. Il server di risorse si basa sul server di autorizzazione per eseguire l'autenticazione e usa le informazioni nei token di connessione rilasciati dal server di autorizzazione per concedere o negare l'accesso alle risorse.

OAuth

Le parti di un flusso di autenticazione usano token di connessione per garantire, verificare ed autenticare un'entità (utente, host o servizio) e per concedere o negare l'accesso alle risorse protette (autorizzazione). I token di connessione in Microsoft Identity Platform vengono formattati come token JSON Web (JWT) .

Tre tipi di token di connessione vengono usati da Identity Platform come token di sicurezza:

  • Token di accesso: i token di accesso vengono rilasciati dal server di autorizzazione all'applicazione client. Il client passa i token di accesso al server di risorse. I token di accesso contengono le autorizzazioni concesse al client dal server di autorizzazione.

  • Token ID: i token ID vengono rilasciati dal server di autorizzazione all'applicazione client. I client usano token ID durante l'accesso degli utenti e per ottenere informazioni di base su di essi.

  • Token di aggiornamento: il client usa un token di aggiornamento o RT, per richiedere nuovi token di accesso e ID dal server di autorizzazione. Il codice deve considerare i token di aggiornamento e il relativo contenuto stringa come dati sensibili perché sono destinati al solo uso da parte del server di autorizzazione.

Registrazione app

L'app client deve avere un modo per considerare attendibili i token di sicurezza rilasciati da Microsoft Identity Platform. Il primo passaggio per stabilire l'attendibilità è registrare l'app. Quando si registra l'app, Identity Platform assegna automaticamente alcuni valori, mentre altri vengono configurati in base al tipo di applicazione.

Due delle impostazioni di registrazione dell'app a cui si fa riferimento più comunemente sono:

  • ID applicazione (client): detto anche ID applicazione e ID client, questo valore viene assegnato all'app dalla piattaforma di gestione delle identità. L'ID client identifica in modo univoco l'app nella piattaforma di gestione delle identità ed è inclusa nei token di sicurezza rilasciati dalla piattaforma.
  • URI di reindirizzamento: il server di autorizzazione usa un URI di reindirizzamento per indirizzare l'agente-utente del proprietario della risorsa (Web browser, app per dispositivi mobili) a un'altra destinazione dopo aver completato l'interazione. Ad esempio, dopo che l'utente finale esegue l'autenticazione con il server di autorizzazione. Non tutti i tipi di client usano URI di reindirizzamento.

La registrazione dell'app contiene anche informazioni sugli endpoint di autenticazione e autorizzazione che verranno usati nel codice per ottenere i token ID e di accesso.

Endpoint

Microsoft Identity Platform offre servizi di autenticazione e autorizzazione usando implementazioni conformi agli standard di OAuth 2.0 e OpenID Connect (OIDC) 1.0. I server di autorizzazione conformi agli standard come Identity Platform forniscono un set di endpoint HTTP da usare in un flusso di autenticazione per eseguire il flusso.

Gli URI dell'endpoint per l'app vengono generati automaticamente quando si registra o si configura l'app. Gli endpoint usati nel codice dell'app dipendono dal tipo dell'applicazione e dalle identità (tipi di account) che devono supportare.

Due endpoint di uso comune sono l'endpoint di autorizzazione e l'endpoint del token. Di seguito sono riportati esempi di endpoint authorize e token:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Per trovare gli endpoint per un'applicazione registrata, nell'Interfaccia di amministrazione di Microsoft Entra passare a:

Identità>Applicazioni>Registrazioni app><la tua applicazione>>Endpoint

Passaggi successivi

Informazioni sui flussi di autenticazione OAuth 2.0 usati da ogni tipo di applicazione e sulle librerie che è possibile usare nelle app per eseguirle:

È consigliabile creare una libreria personalizzata o chiamate HTTP non elaborate per eseguire i flussi di autenticazione. Microsoft Authentication Library è più sicuro e semplice. Tuttavia, se lo scenario impedisce l'uso delle librerie o si vogliono ottenere altre informazioni sull'implementazione di Microsoft Identity Platform, sono disponibili informazioni di riferimento sul protocollo: