Configurare un'applicazione OpenID Connessione OAuth dalla raccolta di app Microsoft Entra
Processo per aggiungere un'applicazione OpenID dalla raccolta
Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un'applicazione cloud Amministrazione istrator.
Passare a Applicazioni di identità>Applicazioni>aziendali.
Selezionare Nuova applicazione nella parte superiore della finestra di dialogo.
Nella casella di ricerca digitare il nome dell'applicazione. Selezionare l'applicazione desiderata dal pannello dei risultati e iscriversi all'applicazione.
Nella pagina Nome dell'applicazione fare clic sul pulsante Iscrizione.
Nota
In questo caso l'amministratore del tenant deve selezionare il pulsante di iscrizione e fornire il consenso all'applicazione. L'applicazione viene quindi aggiunta al tenant esterno, in cui è possibile eseguire le configurazioni. Non è necessario aggiungere l'applicazione in modo esplicito.
Si viene reindirizzati alla pagina Di accesso dell'applicazione o all'ID di Microsoft Entra per le credenziali di accesso.
Una volta eseguita l'autenticazione, l'utente accetta il consenso dalla relativa pagina. Viene quindi visualizzata la home page dell'applicazione.
Nota
È possibile aggiungere solo un'istanza dell'applicazione. Se ne è già stata aggiunta una e si è tentato di fornire nuovamente il consenso, questa non verrà aggiunta una seconda volta nel tenant. È quindi possibile usare logicamente solo un'istanza di app nel tenant.
Guardare il video seguente per aggiungere un'applicazione OpenID dalla raccolta.
Flusso di autenticazione con OpenID Connect
Il flusso di accesso di base include i passaggi seguenti:
Applicazione multi-tenant
Un'applicazione multi-tenant è destinata all'uso in molte organizzazioni, non solo in una. Si tratta generalmente di applicazioni SaaS (Software-as-a-Service) scritte da un fornitore di software indipendente (ISV).
Le applicazioni multi-tenant devono essere sottoposte a provisioning in ogni directory in cui verranno usate. Per la registrazione, richiedono il consenso dell'utente o dell'amministratore. Questo processo di consenso inizia quando un'applicazione viene registrata nella directory e può accedere all'API Graph o magari a un'altra API Web. Quando un utente o un amministratore di un'altra organizzazione esegue l'accesso per usare l'applicazione, viene visualizzata una finestra di dialogo in cui sono indicate le autorizzazioni richieste dall'applicazione.
L'utente o l'amministratore può a questo punto fornire il consenso all'applicazione. Il consenso conferisce all'applicazione l'accesso ai dati indicati e la registra nella directory.
Nota
Se l'applicazione viene resa disponibile agli utenti in più directory, è necessario un meccanismo per determinare il tenant attivo. Un'applicazione a tenant singolo deve cercare un utente solo nella propria directory. Un'applicazione multi-tenant deve identificare un utente specifico da tutte le directory in Microsoft Entra ID.
Per eseguire questa attività, Microsoft Entra ID fornisce un endpoint di autenticazione comune in cui qualsiasi applicazione multi-tenant può indirizzare le richieste di accesso, anziché un endpoint specifico del tenant. Questo endpoint è https://login.microsoftonline.com/common per tutte le directory in Microsoft Entra ID. Un endpoint specifico del tenant può essere ad esempio https://login.microsoftonline.com/contoso.onmicrosoft.com.
L'endpoint comune è importante da considerare quando si sviluppa l'applicazione. È necessaria la logica richiesta per gestire più tenant durante l'accesso, la disconnessione e la convalida del token.
Per impostazione predefinita, Microsoft Entra ID promuove applicazioni multi-tenant. È facile accedervi tra organizzazioni diverse e sono facili da usare dopo aver accettato il consenso.
Framework di consenso
È possibile usare il framework di consenso di Microsoft Entra per sviluppare applicazioni web multi-tenant e client native. Queste applicazioni consentono l'accesso tramite account utente da un tenant di Microsoft Entra, diverso da quello in cui è registrata l'applicazione. Potrebbe dover accedere anche ad API Web, ad esempio:
- L'API Microsoft Graph, per accedere a Microsoft Entra ID, Intune e servizi in Microsoft 365.
- Altre API di servizi Microsoft.
- API Web personalizzate.
Il framework è basato sulla possibilità per un utente o un amministratore di fornire il consenso alla richiesta di registrazione di un'applicazione nella propria directory, che può comportare l'accesso a dati di directory. Una volta ottenuto il consenso, l'applicazione client può chiamare l'API Graph di Microsoft per conto dell'utente e usare le informazioni nel modo necessario.
L'API Microsoft Graph offre l'accesso ai dati in Microsoft 365, ad esempio:
- Calendari e messaggi di Exchange.
- Siti ed elenchi di SharePoint.
- Documenti di OneDrive.
- Blocchi appunti di OneNote.
- Attività di Planner.
- Cartelle di lavoro di Excel.
L'API Graph fornisce anche l'accesso a utenti e gruppi da Microsoft Entra ID e altri oggetti dati da altri servizi cloud Microsoft.
I passaggi seguenti illustrano il funzionamento dell'esperienza di consenso per lo sviluppatore e l'utente dell'applicazione:
Si supponga di avere un'applicazione client Web che deve richiedere autorizzazioni specifiche per accedere a una risorsa o un'API. Il portale di Azure viene usato per dichiarare le richieste di autorizzazione al momento della configurazione. Come altre impostazioni di configurazione, diventano parte delle registrazioni di Microsoft Entra dell'applicazione. Per il percorso della richiesta di autorizzazione è necessario seguire questa procedura:
a. Fare clic su Registrazioni app sul lato sinistro del menu e aprire l'applicazione digitandone il nome nella casella di ricerca.
b. Fare clic su Visualizza le autorizzazioni dell'API.
c. Fare clic su Aggiungi un'autorizzazione.
d. Fare clic su Microsoft Graph.
e. Selezionare le opzioni desiderate da Autorizzazioni delegate e Autorizzazioni applicazione.
Tenere presente che le autorizzazioni dell'applicazione sono state aggiornate. L'applicazione è in esecuzione e un utente sta per usarla per la prima volta. Prima di tutto, l'applicazione deve ottenere un codice di autorizzazione dall'endpoint Microsoft Entra ID /authorize. Il codice di autorizzazione può quindi essere usato per acquisire un nuovo un token di accesso e aggiornamento.
Se l'utente non è già autenticato, l'endpoint Microsoft Entra ID /authorize richiede l'accesso.
Dopo l'accesso dell'utente, Microsoft Entra ID determina se l'utente deve visualizzare una pagina di consenso. Questa decisione dipende dal fatto che l'utente o l'amministratore dell'organizzazione abbia o meno già concesso il consenso dell'applicazione.
Se il consenso non è stato concesso, Microsoft Entra richiede all'utente il consenso e visualizza le autorizzazioni necessarie per il funzionamento. Le autorizzazioni visualizzate nella finestra di dialogo di consenso corrispondono a quelle selezionate nelle autorizzazioni delegate.
Un utente normale può offrire il consenso per alcune autorizzazioni. Altre autorizzazioni richiedono il consenso dell'amministratore del tenant.
Differenza tra consenso dell'amministratore e consenso dell'utente
In qualità di amministratore, è possibile inoltre consentire le autorizzazioni delegate di un'applicazione per conto di tutti gli utenti nel proprio tenant. Il consenso dell'amministratore impedisce che la finestra di dialogo di consenso sia visualizzata per ogni utente nel tenant. Gli utenti con ruolo di amministratore possono fornire il consenso. Nella pagina Impostazioni dell'applicazione selezionare Autorizzazioni necessarie>Concedi consenso amministratore.
Nota
La concessione del consenso esplicito tramite il pulsante Concedi consenso amministratore è ora necessaria per le applicazioni a pagina singola che usano MSAL.js. In caso contrario, l'applicazione non funziona quando viene richiesto il token di accesso.
Le autorizzazioni solo app richiedono il consenso dell'amministratore del tenant. Se l'applicazione richiede un'autorizzazione solo per app e un utente tenta di accedere all'applicazione, viene visualizzato un messaggio di errore che informa che l'utente non è in grado di fornire il consenso.
Se l'applicazione usa autorizzazioni che richiedono il consenso dell'amministratore, è necessario che sia presente un movimento, ad esempio un pulsante o un collegamento, con cui l'amministratore può avviare l'azione. La richiesta inviata dall'applicazione per questa azione è la richiesta di autorizzazione OAuth2/OpenID Connect standard, che include anche il parametro prompt=admin_consent della stringa di query.
Dopo che l'amministratore ha fornito il consenso e l'entità servizio è stata creata nel tenant del cliente, le successive richieste di accesso non richiedono il parametro prompt=admin_consent. Poiché l'amministratore ha deciso che le autorizzazioni richieste sono accettabili, a nessun altro utente nel tenant viene richiesto il consenso da questo punto in poi.
Un amministratore tenant può disabilitare la possibilità che gli utenti normali possano il consenso alle applicazioni. Se questa funzionalità è disabilitata, è necessario usare il consenso dell'amministratore come obbligatorio sempre per l'applicazione nel tenant. Per testare l'applicazione con il consenso dell'utente finale disabilitato, è possibile trovare l'opzione di configurazione nel portale di Azure, nella sezione Impostazioni utente in Applicazioni aziendali.
Il parametro prompt=admin_consent può essere usato anche dalle applicazioni richiedenti autorizzazioni che non necessitano del consenso dell'amministratore. Un esempio è rappresentato da un'applicazione che richiede un'esperienza in cui l'amministratore del tenant "si iscrive" una sola volta e da quel momento non viene richiesto il consenso di altri utenti.
Si immagini che un'applicazione richieda il consenso dell'amministratore e un amministratore esegua l'accesso senza il parametro prompt=admin_consent inviato. Se l'amministratore concede il consenso all'applicazione, viene applicato solo per l'account utente. Gli utenti normali non possono comunque eseguire l'accesso o fornire il consenso all'applicazione. Questa funzionalità è utile se si vuole assegnare all'amministratore del tenant la possibilità di esplorare l'applicazione prima di consentire l'accesso ad altri utenti.