Scenario: applicazione daemon che chiama le API Web

  • Articolo

Questo scenario consente di compilare un'applicazione daemon che chiama le API Web.

Panoramica

L'applicazione può acquisire un token per chiamare un'API Web per conto di se stessa (non per conto di un utente). Questo scenario è utile per le applicazioni daemon. Usa la concessione di credenziali client OAuth 2.0 standard.

Daemon apps

Alcuni esempi di casi d'uso per le app daemon includono;

  • Applicazioni Web usate per effettuare il provisioning o amministrare gli utenti o eseguire processi batch in una directory
  • Applicazioni desktop (ad esempio i servizi Windows nei processi Windows o daemon in Linux) che eseguono processi batch o un servizio del sistema operativo in esecuzione in background
  • API Web che devono modificare le directory, non utenti specifici

Esiste un altro caso comune in cui le applicazioni non daemon usano credenziali client, anche quando agiscono per conto degli utenti. Ciò si verifica quando è necessario accedere a un'API Web o a una risorsa con la propria identità per motivi tecnici. Un esempio è l'accesso ai segreti in Azure Key Vault o database SQL di Azure per una cache.

Non è possibile distribuire un'applicazione daemon nel dispositivo di un utente normale e un utente normale non può accedere a un'applicazione daemon. Solo un set limitato di amministratori IT può accedere ai dispositivi che dispongono di applicazioni daemon in esecuzione. Ciò significa che un attore non valido non può accedere a un segreto client o a un token dal traffico del dispositivo e agire per conto dell'applicazione daemon. Lo scenario dell'applicazione daemon non sostituisce l'autenticazione del dispositivo.

Esempi di applicazioni non daemon:

  • Applicazione per dispositivi mobili che accede a un servizio Web per conto di un'applicazione, ma non per conto di un utente.
  • Un dispositivo IoT che accede a un servizio Web per conto di un dispositivo, ma non per conto di un utente.

Applicazioni che acquisiscono un token per le proprie identità:

  • Le applicazioni client riservate, dato che accedono alle risorse indipendentemente dagli utenti, devono dimostrare la propria identità. Gli amministratori tenant di Microsoft Entra devono concedere l'approvazione a queste app piuttosto sensibili.
  • Aver registrato un segreto (password dell'applicazione o certificato) con l'ID Microsoft Entra. Questo segreto viene passato durante la chiamata a Microsoft Entra ID per ottenere un token.

Specifiche

Gli utenti non possono interagire con un'applicazione daemon perché richiede la propria identità. Questo tipo di applicazione richiede un token di accesso usando l'identità dell'applicazione e presentando l'ID applicazione, le credenziali (password o certificato) e l'URI ID applicazione all'ID Microsoft Entra. Dopo l'autenticazione, il daemon riceve un token di accesso (e un token di aggiornamento) da Microsoft Identity Platform. Questo token viene quindi usato per chiamare l'API Web e viene aggiornato in base alle esigenze.

Poiché gli utenti non possono interagire con le applicazioni daemon, il consenso incrementale non è possibile. Tutte le autorizzazioni API necessarie devono essere configurate durante la registrazione dell'applicazione. Il codice dell'applicazione richiede solo autorizzazioni definite in modo statico. Ciò significa anche che le applicazioni daemon non supporterà il consenso incrementale.

Per gli sviluppatori, l'esperienza end-to-end per questo scenario presenta gli aspetti seguenti:

  • Le applicazioni daemon possono funzionare solo nei tenant di Microsoft Entra. Non sarebbe opportuno creare un'applicazione daemon che tenta di modificare gli account personali Microsoft. Gli sviluppatori di app line-of-business (LOB) creeranno l'app daemon nel tenant. Se si è un ISV, è possibile creare un'applicazione daemon multi-tenant. Ogni amministratore tenant deve fornire il consenso.
  • Durante la registrazione dell'applicazione, l'URI di risposta non è necessario. Condividere segreti o certificati o asserzioni firmate con Microsoft Entra ID. È anche necessario richiedere le autorizzazioni dell'applicazione e concedere il consenso amministratore per usare tali autorizzazioni per le app.
  • La configurazione dell'applicazione deve fornire le credenziali client come condivise con Microsoft Entra ID durante la registrazione dell'applicazione.
  • L'ambito usato per acquisire un token con il flusso delle credenziali client deve essere un ambito statico.

Se non si ha familiarità con la gestione delle identità e degli accessi (IAM) con OAuth 2.0 e OpenID Connessione o anche solo una novità di IAM in Microsoft Identity Platform, il set di articoli seguente dovrebbe essere elevato nell'elenco di lettura.

Anche se non è necessaria la lettura prima di completare la prima guida introduttiva o esercitazione, illustrano gli argomenti integrali della piattaforma e la loro familiarità con essi consentiranno di seguire il percorso man mano che si creano scenari più complessi.

Autenticazione e autorizzazione

Microsoft Identity Platform

Passaggi successivi

Passare all'articolo successivo in questo scenario, Registrazione app.