OAuth 2.0 e OpenID Connessione (OIDC) in Microsoft Identity Platform
Non è necessario conoscere OAuth o OpenID Connessione (OIDC) a livello di protocollo 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, conoscendo 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 Connessione. Questi scambi sono spesso detti flussi di autenticazione o flussi di autenticazione.
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 trust 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. Il client viene spesso definito applicazione client, applicazione o app.
Proprietario della risorsa: il proprietario della risorsa in un flusso di autenticazione è in genere l'utente dell'applicazione o l'utente finale nella terminologia OAuth. L'utente finale "è proprietario" della risorsa protetta (i relativi dati) a cui l'app accede per suo conto. Il proprietario della risorsa può 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 del proprietario di una 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 in 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 Web JSON (JWT).
Tre tipi di token di connessione vengono usati da Identity Platform come token di sicurezza:
Token di accesso: i token di accesso vengono emessi 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 emessi 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 all'uso solo dal 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à consiste nel registrare l'app. Quando si registra l'app, Identity Platform assegna automaticamente alcuni valori, mentre altri vengono configurati in base al tipo dell'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 che si verificano i problemi della 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 l'ID e i token di accesso.
Endpoint
Microsoft Identity Platform offre servizi di autenticazione e autorizzazione usando implementazioni conformi agli standard di OAuth 2.0 e OpenID Connessione (OIDC) 1.0. I server di autorizzazione conformi agli standard come Identity Platform forniscono un set di endpoint HTTP da usare dalle parti 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 authorize endpoint 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:
Applicazioni> di identità>Registrazioni app>< EndpointYOUR-APPLICATION>>
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 più semplice. Tuttavia, se lo scenario impedisce l'uso delle librerie o si vuole ottenere altre informazioni sull'implementazione di Microsoft Identity Platform, sono disponibili informazioni di riferimento sul protocollo:
- Flusso di concessione del codice di autorizzazione - App a pagina singola (SPA), app per dispositivi mobili, applicazioni native (desktop)
- Flusso delle credenziali client - Processi lato server, script, daemon
- Flusso on-behalf-of (OBO) - API Web che chiamano un'altra API Web per conto di un utente
- OpenID Connessione - Accesso utente, disconnesso e Single Sign-On (SSO)