Condividi tramite


API JavaScript di autenticazione

Il front-end di Fabric offre un'API JavaScript per i carichi di lavoro di Fabric per acquisire un token per l'applicazione in Microsoft Entra ID. Il presente articolo descrive questa API.

API

acquireAccessToken(params: AcquireAccessTokenParams): Promise<AccessToken>;  
export interface AcquireAccessTokenParams {
    additionalScopesToConsent?: string[];  
    claimsForConditionalAccessPolicy?: string;
    promptFullConsent?: boolean;
}

L'API restituisce un oggetto AccessToken che contiene il token stesso e una data di scadenza per il token.

Per chiamare l'API nell'esempio front-end, creare un articolo campione e scorrere verso il basso e selezionare Passare alla pagina Autenticazione. Da qui è possibile selezionare Recuperare token di accesso per ricevere nuovamente un token.

Screenshot che mostra la sezione autenticazione.

Consensi

Per comprendere perché sono necessari i consensi, passare a Consensi utente e amministratore in Microsoft Entra ID .

Nota

I consensi sono necessari per il funzionamento di CRUD/Processi e l'acquisizione di token tra tenant.

Come funzionano i consensi nei carichi di lavoro di Fabric?

Per concedere un consenso per un'applicazione specifica, Fabric FE crea un'istanza MSAL configurata con l'ID di applicazione del carico di lavoro e richiede un token per gli ambiti forniti (additionalScopesToConsent- vedere AcquireAccessTokenParams).

Quando si richiede un token con l'applicazione del carico di lavoro per un ambito specifico, Microsoft Entra ID mostra un consenso popup nel caso in cui non sia presente e quindi reindirizza la finestra popup all'URI di reindirizzamento configurato nell'applicazione.

In genere l'URI di reindirizzamento si trova nello stesso dominio della pagina che ha richiesto il token, in modo che la pagina possa accedere al popup e chiuderla.

In questo caso, non si trova nello stesso dominio, poiché Fabric richiede il token e l'URI di reindirizzamento del carico di lavoro non si trova nel dominio Fabric. Quindi, quando si apre la finestra di dialogo di consenso, questa deve essere chiusa manualmente dopo il reindirizzamento. Non viene usato il codice restituito nell'URI di reindirizzamento, quindi è sufficiente chiuderlo automaticamente (quando Microsoft Entra ID reindirizza il popup all'URI di reindirizzamento viene semplicemente chiuso).

È possibile visualizzare il codice o la configurazione dell'URI di reindirizzamento nel file index.ts.

Ecco un esempio di popup di consenso per la "app del carico di lavoro personale" e le relative dipendenze (archiviazione e Power BI) configurate durante l'installazione dell'autenticazione:

Screenshot della finestra di dialogo delle autorizzazioni.

Un altro modo per concedere il consenso nel tenant principale (facoltativo)

Per ottenere un consenso nel tenant principale dell'applicazione, è possibile chiedere all'amministratore tenant di concedere un consenso per l'intero tenant usando un URL nel formato seguente (inserire il proprio ID tenant e l'ID client):

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}

AcquireAccessTokenParams

Quando si chiama l'API JS acquireAccessToken, è possibile fornire tre parametri:

  • additionalScopesToConsent: altri ambiti per cui richiedere il consenso, ad esempio scenari di riconciliazione.
  • claimsForConditionalAccessPolicy: attestazioni restituite dall'ID Microsoft Entra quando i flussi OBO hanno esito negativo, ad esempio OBO richiede l'autenticazione a più fattori.
  • promptFullConsent: richiede una finestra di consenso completa delle dipendenze statiche dell'applicazione carichi di lavoro.

additionalScopesToConsent

Se il front-end del carico di lavoro richiede un token da usare per le chiamate al back-end del carico di lavoro, questo parametro deve essere Null. Il back-end del carico di lavoro non può eseguire OBO sul token ricevuto a causa di un errore di consenso mancante, in tal caso il back-end del carico di lavoro dovrà propagare l'errore al front-end del carico di lavoro e fornire questo parametro.

claimsForConditionalAccessPolicy

Questo parametro viene usato quando si verificano errori OBO nel carico di lavoro BE a causa di alcuni criteri di accesso condizionale configurati nel tenant.

Gli errori OBO causati dai criteri di accesso condizionale restituiscono una stringa denominata "claims". Questa stringa deve essere inviata al carico di lavoro FE in cui FE richieda un token e passi la stringa claim come claimsForConditionalAccessPolicy. Per altre informazioni, vedere Gestione dell'autenticazione a più fattori (MFA), dell'accesso condizionale e del consenso incrementale.

Per degli esempi di risposta quando le operazioni OBO hanno esito negativo a causa del consenso mancante o dei criteri di accesso condizionale, vedere l'uso di AuthenticationService AddBearerClaimToResponse nell'esempio BE.

Per altre informazioni su questo argomento aggiuntivoScopesToConsent e claimsForConditionalAccessPolicy e vedere esempi di utilizzo, vedere Linee guida per l'autenticazione del carico di lavoro e approfondimento.

promptFullConsent

Quando viene passato come true, viene visualizzato un consenso completo delle dipendenze statiche per l'utente indipendentemente dal fatto che abbia fornito un consenso in precedenza o meno. Un esempio di utilizzo per questo parametro consiste nell'aggiungere un pulsante all'esperienza utente in cui l'utente può usarlo per concedere il consenso completo al carico di lavoro.