Condividi tramite

Credenziali della password del proprietario delle risorse di Microsoft Identity Platform e OAuth 2.0

  • Articolo

Microsoft Identity Platform offre supporto per la concessione di OAuth 2.0 Resource Owner Password Credentials (ROPC), che consente a un'applicazione di eseguire l'accesso dell'utente gestendo direttamente la password. Questo articolo descrive come programmare direttamente con il protocollo nella tua applicazione. Quando possibile, è consigliabile usare le librerie di autenticazione Microsoft supportate (MSAL) per acquisire i token e chiamare api Web protette. Dai un'occhiata anche alle app di esempio che usano MSAL.

Avvertimento

Microsoft consiglia di non usare il flusso ROPC; non è compatibile con l'autenticazione a più fattori (MFA). Nella maggior parte degli scenari sono disponibili alternative più sicure e consigliate. Questo flusso richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi che non sono presenti in altri flussi. È consigliabile usare questo flusso solo quando i flussi più sicuri non sono validi.

Importante

  • La piattaforma di identità Microsoft supporta solo l'autorizzazione ROPC all'interno dei tenant Microsoft Entra, e non gli account personali. Ciò significa che è necessario usare un endpoint specifico del tenant (https://login.microsoftonline.com/{TenantId_or_Name}) o l'endpoint organizations.
  • Gli account personali invitati a un tenant di Microsoft Entra non possono usare il flusso ROPC.
  • Gli account che non dispongono di password non possono accedere con ROPC, ovvero funzionalità come l'accesso TRAMITE SMS, FIDO e l'app Authenticator non funzioneranno con tale flusso. Se l'app o gli utenti richiedono queste funzionalità, usare un tipo di concessione diverso da ROPC.
  • Se gli utenti devono usare multi-factor authentication (MFA) per accedere all'applicazione, verranno bloccati.
  • ROPC non è supportato in scenari di federazione di identità ibride (ad esempio, Microsoft Entra ID e AD FS utilizzati per autenticare gli account locali). Se gli utenti vengono reindirizzati a pagina intera a un provider di identità locale, l'ID Microsoft Entra non è in grado di testare il nome utente e la password con tale provider di identità. L'autenticazione pass-through è supportata con ROPC, tuttavia.
  • Un'eccezione a uno scenario di federazione di identità ibrida è la seguente: la policy di individuazione dell'area di autenticazione principale con AllowCloudPasswordValidation impostato su TRUE consentirà al flusso ROPC di operare per gli utenti federati quando una password locale viene sincronizzata nel cloud. Per altre informazioni, vedere Abilitare l'autenticazione ROPC diretta degli utenti federati per le applicazioni legacy.
  • Le password con spazi vuoti iniziali o finali non sono supportate dal flusso ROPC.

Come eseguire la migrazione da ROPC

Man mano che l'autenticazione a più fattori diventa più diffusa, alcune API Web Microsoft accetteranno solo i token di accesso se hanno superato i requisiti di autenticazione a più fattori. Le applicazioni e i rig di test basati su ROPC verranno bloccati. Microsoft Entra non emetterà il token o la risorsa rifiuterà la richiesta.

Se si utilizza ROPC per ottenere i token necessari per chiamare le API protette downstream, passare a una strategia sicura di acquisizione dei token.

Quando il contesto utente è disponibile

Se un utente finale deve accedere a una risorsa, l'applicazione client che agisce per suo conto deve usare una forma di autenticazione interattiva. L'utente finale può essere sottoposto a richiesta per l'autenticazione a più fattori solo quando è richiesto nel browser.

  • Per le applicazioni Web:
  • Le API Web non possono visualizzare un browser. Devono invece restituire una richiesta di verifica all'applicazione client. Per informazioni dettagliate, vedere API Web e sfidare gli utenti nelle API Web.
  • Le applicazioni desktop devono usare l'autenticazione basata su broker. I broker usano l'autenticazione basata su browser, in modo da poter applicare l'autenticazione a più fattori e anche abilitare il comportamento più sicuro possibile.
  • Le applicazioni per dispositivi mobili devono anche essere configurate per l'uso dell'autenticazione basata su broker (Authenticator, Portale aziendale).

Quando il contesto utente non è disponibile

Esempi di scenari in cui non è coinvolto alcun contesto utente può essere, ma non è limitato ai seguenti:

  • Script in esecuzione come parte di una pipeline di integrazione continua.
  • Un servizio che deve chiamare una risorsa per conto di se stesso, senza dettagli utente.

Gli sviluppatori di applicazioni devono usare 'autenticazione dell'entità servizio, illustrata negli esempi del daemon . L'autenticazione a più fattori non si applica ai Principali del servizio.

Esistono diversi modi per eseguire l'autenticazione come entità servizio:

  • Se l'app è in esecuzione nell'infrastruttura di Azure, usa identità gestita. L'identità gestita elimina il sovraccarico di gestione e rotazione di segreti e certificati.
  • Se l'app è in esecuzione in un sistema gestito da un altro provider di identità conforme a OAuth2, ad esempio GitHub, usare credenziali di identità federate.
  • Se non è possibile usare un'identità gestita o un'identità federata, usare una credenziale del certificato .

Avvertimento

Non usare l'autenticazione del Service Principal quando è disponibile il contesto utente. L'accesso tramite app è intrinsecamente di alto privilegio, spesso concedendo accesso a livello di inquilino e consentendo potenzialmente a un attore malintenzionato di accedere ai dati dei clienti per tutti gli utenti.

Diagramma del protocollo

Il diagramma seguente illustra il flusso ROPC.

Diagramma che mostra il flusso delle credenziali della password del proprietario della risorsa

Richiesta di autorizzazione

Il flusso ROPC è una singola richiesta; invia l'identificazione client e le credenziali dell'utente al provider di identità e riceve i token in cambio. Il client deve richiedere l'indirizzo di posta elettronica dell'utente (UPN) e la password prima di farlo. Subito dopo una richiesta riuscita, il client deve eliminare in modo sicuro le credenziali dell'utente dalla memoria. Non deve mai salvarli.

// Line breaks and spaces are for legibility only.  This is a public client, so no secret is required.

POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Parametro Condizione Descrizione
tenant Obbligatorio La directory tenant in cui desideri loggare l'utente. Il tenant può essere in formato GUID o nome descrittivo. Tuttavia, il parametro non può essere impostato su common o consumers, ma può essere impostato su organizations.
client_id Obbligatorio ID applicazione (client) che la pagina del centro di amministrazione di Microsoft Entra - Registrazioni app ha assegnato alla tua app.
grant_type Obbligatorio Deve essere impostato su password.
username Obbligatorio Indirizzo di posta elettronica dell'utente.
password Obbligatorio Password dell'utente.
scope Raccomandato Elenco delimitato da spazi di ambiti o autorizzazioni richieste dall'app. In un flusso interattivo, l'amministratore o l'utente deve fornire il consenso a questi ambiti in anticipo.
client_secret A volte necessario Se l'app è un client pubblico, non è possibile includere il client_secret o client_assertion. Se l'app è un client riservato, deve essere inclusa.
client_assertion A volte necessario Una forma diversa di client_secret, generata usando un certificato. Per altre informazioni, vedere le credenziali del certificato .

Risposta di autenticazione riuscita

L'esempio seguente mostra una risposta di token riuscita.

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Parametro Formato Descrizione
token_type Stringa Assicurarsi di impostare sempre su Bearer.
scope Stringhe separate da spazi Se è stato restituito un token di accesso, questo parametro elenca gli ambiti per cui il token di accesso è valido.
expires_in Int Numero di secondi per cui il token di accesso incluso è valido.
access_token Stringa opaca Rilasciato per gli ambiti e richiesti.
id_token JWT Emesso se il parametro scope originale includeva l'ambito openid.
refresh_token Stringa opaca Generato se il parametro scope originale includeva offline_access.

È possibile usare il token di aggiornamento per acquisire nuovi token di accesso e token di aggiornamento usando lo stesso flusso descritto nella documentazione del flusso di codice OAuth .

Avvertimento

Non tentare di convalidare o leggere i token per qualsiasi API di cui non si è proprietari, inclusi i token in questo esempio, nel codice. I token per i servizi Microsoft possono usare un formato speciale che non verrà convalidato come token JWT e potrebbe anche essere crittografato per gli utenti consumer (account Microsoft). Mentre si leggono i token è uno strumento utile per il debugging e l'apprendimento, non fare affidamento su questo nel codice o presumere particolari sui token che non appartengono a un'API che controlli.

Risposta di errore

Se l'utente non ha specificato il nome utente o la password corretti o se il client non ha ricevuto il consenso richiesto, l'autenticazione avrà esito negativo.

Errore Descrizione azione del cliente
invalid_grant Autenticazione non riuscita Le credenziali non sono corrette o il client non ha il consenso per gli ambiti richiesti. Se gli ambiti non vengono concessi, verrà restituito un errore di consent_required. Per risolvere questo errore, il client deve inviare l'utente a un prompt interattivo usando una visualizzazione Web o un browser.
invalid_request La richiesta è stata costruita in modo non corretto Il tipo di concessione non è supportato nei contesti di autenticazione /common o /consumers. Usare invece /organizations o un ID tenant.

Ulteriori informazioni

Per un esempio di implementazione del flusso ROPC, vedere l'esempio di codice dell'applicazione console .NET su GitHub.