Informazioni sull'autenticazione

Per autenticazione si intende la richiesta di credenziali legittime a una parte, che costituiscono la base per la creazione di un'entità di sicurezza da usare per il controllo delle identità e di accesso. In termini semplici, si tratta del processo di dimostrare la propria identità. In lingua inglese, il termine autenticazione viene talvolta abbreviato in AuthN.

Per autorizzazione si intende la concessione a un'entità di sicurezza autenticata dell'autorizzazione a eseguire determinate operazioni. L'autorizzazione specifica a quali dati l'utente può accedere e le operazioni che può eseguirvi. In lingua inglese, il termine autorizzazione viene talvolta abbreviato in AuthZ.

Azure Active Directory per gli sviluppatori (v1.0) (Azure AD) semplifica l'autenticazione per gli sviluppatori di applicazioni fornendo identità come servizio, con supporto per protocolli standard del settore, ad esempio OAuth 2.0 e OpenID Connect, nonché librerie open source per piattaforme diverse per iniziare rapidamente la codifica.

Nel modello di programmazione di Azure AD esistono due casi d'uso principali.

• Durante un flusso di concessione di autorizzazione OAuth 2.0: quando il proprietario delle risorse concede l'autorizzazione all'applicazione client che può così accedere alle risorse del proprietario.
• Durante l'accesso alle risorse da parte del client: l'implementazione viene eseguita dal server di risorse, usando i valori di attestazione presenti nel token di accesso come base per le decisioni relative al controllo di accesso.

Nozioni di base di autenticazione in Azure AD

Si consideri lo scenario più semplice in cui è necessaria l'identità, ovvero quello in cui un utente deve eseguire l'autenticazione a un'applicazione Web in un Web browser. Il diagramma seguente illustra questo scenario:

Ecco cosa è necessario conoscere i vari componenti illustrati nel diagramma:

• Azure AD è il provider di identità. Il provider di identità è responsabile della verifica dell'identità degli utenti e delle applicazioni presenti nella directory di un'organizzazione e rilascia token di sicurezza al termine dell'autenticazione di tali utenti e applicazioni.
• Un'applicazione che vuole eseguire l'esternalizzazione dell'autenticazione in Azure AD deve essere registrata in Azure Active Directory (Azure AD). che registra e identifica in modo univoco l'app nella directory.
• Gli sviluppatori possono usare le librerie di autenticazione open source di Azure AD per semplificare l'autenticazione gestendo direttamente i dettagli del protocollo. Per altre informazioni, vedere Librerie di autenticazione 2.0 e Librerie di autenticazione 1.0 di Microsoft Identity Platform.
• Dopo l'autenticazione di un utente, l'applicazione deve convalidare il token di sicurezza dell'utente per assicurarsi che l'autenticazione sia riuscita. È possibile trovare guide introduttive, esercitazioni ed esempi di codice in un'ampia gamma di linguaggi e framework che illustrano le operazioni che l'applicazione deve eseguire.
  • Per compilare in modo rapido un'app e aggiungere funzionalità, ad esempio il recupero e l'aggiornamento dei token, l'accesso di un utente, la visualizzazione di alcune informazioni utente e altro ancora, vedere la sezione Guide introduttive della documentazione.
  • Per ottenere procedure dettagliate basate su scenari specifici per attività di sviluppo relative all'autenticazione primarie, ad esempio il recupero di token di accesso e il relativo uso in chiamate all'API Microsoft Graph e ad altre API, l'implementazione dell'accesso con Microsoft tramite un'app basata su Web browser tradizionale tramite OpenID Connect e altro ancora, vedere la sezione Esercitazioni della documentazione.
  • Per scaricare esempi di codice, vedere GitHub.
• Il flusso di richieste e risposte per il processo di autenticazione dipende dal protocollo di autenticazione usato, ad esempio OAuth 2.0, OpenID Connect, WS-Federation o SAML 2.0. Per altre informazioni sui protocolli, vedere la sezione Concetti > del protocollo di autenticazione della documentazione.

Nello scenario di esempio precedente è possibile classificare le app in base ai due ruoli seguenti:

• App che devono accedere in modo sicuro alle risorse
• App che rivestono il ruolo della risorsa stessa

Modo in cui ogni flusso emette token e codici

A seconda della compilazione del client, può usare uno o più flussi di autenticazione supportati da Azure AD. Questi flussi possono produrre un'ampia gamma di token (id_tokens, token di aggiornamento, token di accesso) e codici di autorizzazione e richiedono token diversi per consentirne il funzionamento. Questo grafico offre una panoramica:

I token emessi tramite la modalità implicita hanno una limitazione di lunghezza perché vengono passati di nuovo al browser tramite l'URL (dove response_mode è query o fragment). Alcuni browser hanno un limite delle dimensioni dell'URL che può essere inserito nella barra del browser e hanno esito negativo quando è troppo lungo. Di conseguenza, questi token non dispongono di attestazioni groups o wids.

Ora che è disponibile una panoramica dei concetti di base, continuare a leggere per comprendere il modello dell'app e l'API di identità, le modalità di funzionamento del provisioning in Azure AD e i collegamenti a informazioni dettagliate sugli scenari comuni supportati da Azure AD.

Modello applicativo

Azure AD rappresenta le applicazioni basate su un modello specifico progettato per soddisfare due funzioni principali indicate di seguito.

• Identificare l'app in base ai protocolli di autenticazione supportati : ciò comporta l'enumerazione di tutti gli identificatori, gli URL, i segreti e le informazioni correlate necessarie al momento dell'autenticazione. A questo punto, Azure AD:

  • Contiene tutti i dati necessari per supportare l'autenticazione in fase di esecuzione.
  • Contiene tutti i dati per decidere quali risorse potrebbero essere necessarie a un'app per eseguire l'accesso e per stabilire se una determinata richiesta deve essere soddisfatta e in quali circostanze.
  • Offre l'infrastruttura per l'implementazione del provisioning dell'app nel tenant per gli sviluppatori di app e in un altro tenant di Azure AD.

• Gestire il consenso dell'utente durante l'ora di richiesta del token e facilitare il provisioning dinamico delle app tra i tenant - Qui, Azure AD:

  • Consente a utenti e amministratori di concedere o negare dinamicamente il consenso all'app di accedere alle risorse per loro conto.
  • Consente agli amministratori di decidere quali app sono autorizzati a eseguire e quali utenti possono usare app specifiche, nonché la modalità di accesso alle risorse di directory.

In Azure AD, un oggetto applicazione descrive un'applicazione come entità astratta. Gli sviluppatori lavorano con le applicazioni. In fase di distribuzione Azure AD usa un oggetto applicazione specificato come un progetto per creare un'entità servizio, che rappresenta un'istanza concreta di un'applicazione in un tenant oppure in una directory. L'entità servizio definisce ciò che l'app può effettivamente eseguire in una directory di destinazione specifica, chi può usarla, a quali risorse può accedere e così via. Azure AD crea un'entità servizio da un oggetto applicazione tramite il consenso.

Il diagramma seguente illustra un flusso di provisioning di Azure AD semplificato basato su consenso. Sono presenti due tenant (A e B), in cui il tenant A è proprietario dell'applicazione e il tenant B crea un'istanza dell'applicazione tramite un'entità servizio.

In questo flusso di provisioning:

1. Un utente del tenant B prova ad accedere con l'app, l'endpoint di autorizzazione richiede un token per l'applicazione.
2. Le credenziali dell'utente vengono acquisite e verificate per l'autenticazione
3. All'utente viene richiesto di specificare il consenso per l'app per ottenere l'accesso al tenant B
4. Azure AD usa l'oggetto applicazione nel tenant A come progetto per la creazione di un'entità servizio nel tenant B
5. L'utente riceve il token richiesto

È possibile ripetere questo processo ogni volta che si desidera per altri tenant (C, D e così via). Il tenant A mantiene il progetto per l'app (oggetto applicazione). Gli utenti e amministratori di tutti gli altri tenant in cui all'app viene dato il consenso mantengono il controllo su ciò che l'applicazione può eseguire tramite l'oggetto entità servizio corrispondente in ogni tenant. Per altre informazioni, vedere Oggetti applicazione e oggetti entità servizio in Microsoft Identity Platform.

Attestazioni nei token di sicurezza di Azure AD

I token di sicurezza (token di accesso e ID) emessi da Azure AD contengono attestazioni o asserzioni di informazioni sull'oggetto autenticato. Le applicazioni possono usare le attestazioni per varie attività, tra cui:

• Convalidare il token
• Identificare il tenant di directory dell'oggetto
• Visualizzare le informazioni utente
• Determinare l'autorizzazione dell'oggetto

Le attestazioni presenti in un determinato token di sicurezza dipendono dal tipo di token, dal tipo di credenziali usate per autenticare l'utente e dalla configurazione dell'applicazione.

La tabella seguente fornisce una breve descrizione dei tipi di attestazione generati da Azure AD. Per informazioni più dettagliate, vedere i token di accesso e i token ID emessi da Azure AD.

Passaggi successivi

• Informazioni sui tipi di applicazioni supportati in Microsoft Identity Platform