Errors

Konfigurationsfel för webbläsarautentisering

simulerad_offentlig_klientapplikation_anropad

Felmeddelande: Stub-instansen av det offentliga klientprogrammet anropades. Om du använder msal-react, se till att kontexten inte används utan en provider.

Se fel för msal-react

BrowserAuthErrors

Interaktion_pågår

Felmeddelande: Interaktion pågår för närvarande. Kontrollera att interaktionen har slutförts innan du anropar ett interaktivt API.

Det här felet utlöses när ett interaktivt API (loginPopup, , loginRedirectacquireTokenPopup, acquireTokenRedirect) anropas medan ett annat interaktivt API fortfarande pågår. Inloggnings- och acquireToken-API:erna är asynkrona, så du måste se till att de resulterande löftena har lösts innan du anropar en annan.

Använda `loginPopup` eller `acquireTokenPopup`

Se till att löftet som returneras från dessa API:er har lösts innan du anropar ett annat.

❌ Följande exempel genererar det här felet eftersom loginPopup det fortfarande pågår när acquireTokenPopup anropas:

const request = { scopes: ["openid", "profile"] };
loginPopup();
acquireTokenPopup(request);

✔️ För att lösa detta bör du se till att alla interaktiva API:er har lösts innan du anropar en annan:

const request = { scopes: ["openid", "profile"] };
await msalInstance.loginPopup();
await msalInstance.acquireTokenPopup(request);

Använda `loginRedirect` eller `acquireTokenRedirect`

När du använder omdirigerings-API:er handleRedirectPromise måste anropas när du returnerar från omdirigeringen. Detta säkerställer att tokensvaret från servern hanteras korrekt och att tillfälliga cacheposter rensas. Det här felet utlöses när handleRedirectPromise det inte har haft en chans att slutföras innan programmet anropar loginRedirect eller acquireTokenRedirect.

❌ Följande exempel genererar det här felet eftersom handleRedirectPromise det fortfarande bearbetar svaret från ett tidigare loginRedirect anrop när loginRedirect det anropas en andra gång:

msalInstance.handleRedirectPromise();

const accounts = msalInstance.getAllAccounts();
if (accounts.length === 0) {
    // No user signed in
    msalInstance.loginRedirect();
}

✔️ För att lösa problemet bör du vänta på att handleRedirectPromise slutförs innan du anropar ett interaktivt API:

await msalInstance.handleRedirectPromise();

const accounts = msalInstance.getAllAccounts();
if (accounts.length === 0) {
    // No user signed in
    msalInstance.loginRedirect();
}

Eller alternativt:

msalInstance
    .handleRedirectPromise()
    .then((tokenResponse) => {
        if (!tokenResponse) {
            const accounts = msalInstance.getAllAccounts();
            if (accounts.length === 0) {
                // No user signed in
                msalInstance.loginRedirect();
            }
        } else {
            // Do something with the tokenResponse
        }
    })
    .catch((err) => {
        // Handle error
        console.error(err);
    });

Obs! Om du anropar loginRedirect eller acquireTokenRedirect från en sida som inte är din redirectUri måste du se till att handleRedirectPromise anropas och inväntas på både sidan redirectUri och den sida som du initierade omdirigeringen från. Det beror på att sidan redirectUri initierar en omdirigering tillbaka till sidan som ursprungligen anropades loginRedirect och den sidan bearbetar tokensvaret.

Wrapper-bibliotek

Om du använder något av våra wrapper-bibliotek (React eller Angular) kan du läsa feldokumentationen för dessa specifika bibliotek för fler anledningar till att du kan få det här felet:

Om du inte använder något av omslutningsbiblioteken men är orolig för att ditt program kan utlösa samtidiga interaktiva begäranden bör du kontrollera om någon annan interaktion pågår innan du anropar en interaktion i din tokenanskaffningsmetod. Du kan uppnå detta genom att implementera ett globalt programtillstånd eller en sändningstjänst osv. som genererar aktuell MSAL-interaktionsstatus via MSAL Events API.

❌ Följande exempel genererar det här felet eftersom acquireTokenPopup i catch-blocket inte kontrollerar om det finns en annan interaktion för tillfället:

async function myAcquireToken(request) {
    const msalInstance = getMsalInstance(); // get the msal application instance

    const tokenRequest = {
        account: msalInstance.getActiveAccount() || null;
        ...request
    };

    let tokenResponse;

    try {
        // attempt silent acquisition first
        tokenResponse = await msalInstance.acquireTokenSilent(tokenRequest);
    } catch (error) {
        if (error instanceof InteractionRequiredAuthError) {
            try {
                tokenResponse = await msalInstance.acquireTokenPopup(tokenRequest);
            } catch (err) {
                console.log(err);
                // handle other errors
            }
        }

        console.log(error);
        // handle other errors
    }

    return tokenResponse;
};

const request = {
    scopes: ["User.Read"]
};

myAcquireToken(request);
myAcquireToken(request);

✔️ För att lösa problemet bör du vänta tills interaktionsstatusen är None innan du anropar något annat interaktivt API:

async function myAcquireToken(request) {
    const msalInstance = getMsalInstance(); // get the msal application instance

    const tokenRequest = {
        account: msalInstance.getActiveAccount() || null;
        ...request
    };

    let tokenResponse;

    try {
        // attempt silent acquisition first
        tokenResponse = await msalInstance.acquireTokenSilent(tokenRequest);
    } catch (error) {
        if (error instanceof InteractionRequiredAuthError) {
            // check for any interactions
            if (myGlobalState.getInteractionStatus() !== InteractionStatus.None) {
                // throw a new error to be handled in the caller below
                throw new Error("interaction_in_progress");
            } else {
                // no interaction, invoke popup flow
                tokenResponse = await msalInstance.acquireTokenPopup(tokenRequest);
            }
        }

        console.log(error);
        // handle other errors
    }

    return tokenResponse;
};

async function myInteractionInProgressHandler() {
    /**
     * "myWaitFor" method polls the interaction status via getInteractionStatus() from
     * the application state and resolves when it's equal to "None".
     */
    await myWaitFor(() => myGlobalState.getInteractionStatus() === InteractionStatus.None);

    // wait is over, call myAcquireToken again to re-try acquireTokenSilent
    return (await myAcquireToken(tokenRequest));
};

const request = {
    scopes: ["User.Read"]
};

myAcquireToken(request).catch((e) => myInteractionInProgressHandler());
myAcquireToken(request).catch((e) => myInteractionInProgressHandler());

Felsökningssteg

Aktivera utförlig loggning och spåra händelseordningen. Kontrollera att handleRedirectPromise anropas och returneras innan något login ELLER acquireToken API anropas.

Om du inte kan förstå varför det här felet uppstår ber vi dig att skapa ett ärende och vara beredd att dela följande information:

Utförliga loggar
En exempelapp och/eller kodfragment som vi kan använda för att återskapa problemet
Uppdatera sidan. Försvinner felet?
Öppna programmet på en ny flik. Försvinner felet?

block_iframe_reload

Felmeddelande: Begäran blockerades i en iframe eftersom MSAL identifierade ett autentiseringssvar.

Det här felet uppstår när du anropar ssoSilent eller acquireTokenSilent och sidan som används som din redirectUri försöker anropa funktionen login eller acquireToken. Vår rekommenderade åtgärd för detta är att ange din redirectUri till en tom sida som inte implementerar MSAL när du anropar tysta API:er. Detta kommer också att ha den extra fördelen att förbättra prestanda eftersom den dolda iframe inte behöver återge din sida.

✔️ Du kan göra detta per begäran, till exempel:

msalInstance.acquireTokenSilent({
    scopes: ["User.Read"],
    redirectUri: "http://localhost:3000/blank.html",
});

Kom ihåg att du måste registrera den här nya redirectUri på din appregistrering.

Om du inte vill använda en dedikerad redirectUri för detta ändamål bör du i stället se till att du redirectUri inte försöker anropa MSAL-API:er när de återges i den dolda iframe som används av de tysta API:erna.

monitor_window_timeout

Felmeddelanden:

Tokenförvärvet i iframe misslyckades på grund av tidsgränsen.

Det här felet kan uppstå när du anropar ssoSilent, acquireTokenSilentacquireTokenPopup eller loginPopup och det finns flera orsaker till att detta kan inträffa. Det här är några av de vanligaste:

Sidan som du använder som din redirectUri tar bort eller manipulerar hashvärdet
Sidan som du använder som din redirectUri omdirigeras automatiskt till en annan sida
Du begränsas av din identitetsleverantör
Din identitetsleverantör omdirigerade dig inte tillbaka till din redirectUri.

Viktigt: Om ditt program använder ett routerbibliotek (t.ex. React Router, Angular Router) kontrollerar du att det inte tar bort hashen eller automatisk omdirigering medan MSAL-tokenanskaffning pågår. Om möjligt är det bäst om sidan redirectUri inte anropar routern alls.

Problem som orsakas av redirectUri-sidan

När du gör ett tyst anrop öppnas i vissa fall en iframe och navigerar till din identitetsproviders auktoriseringssida. När identitetsprovidern har godkänt användaren omdirigeras iframe tillbaka till redirectUri med auktoriseringskoden eller felinformationen i hash-fragmentet. MSAL-instansen som körs i ramen eller fönstret där begäran ursprungligen skickades kommer att extrahera den här svarshashen och bearbeta den. Om du redirectUri tar bort eller manipulerar den här hashen eller navigerar till en annan sida innan MSAL har extraherat den får du det här timeoutfelet.

✔️ För att lösa det här problemet bör du se till att sidan du använder som din redirectUri inte gör något av dessa saker, åtminstone när den läses in i ett popup-fönster eller iframe. Vi rekommenderar att du använder en tom sida som din redirectUri för tysta och popup-flöden för att säkerställa att inget av dessa kan inträffa.

Du kan göra detta per begäran, till exempel:

msalInstance.acquireTokenSilent({
    scopes: ["User.Read"],
    redirectUri: "http://localhost:3000/blank.html",
});

Kom ihåg att du måste registrera den här nya redirectUri på din appregistrering.

Anmärkningar om Angular och React:

Om du använder @azure/msal-angular bör din redirectUri-sida inte skyddas av MsalGuard.
Om du använder @azure/msal-react, bör din redirectUri-sida inte rendera MsalAuthenticationComponent eller använda hooken useMsalAuthentication.

Problem som orsakas av identitetsprovidern

Throttling

En av de vanligaste orsakerna till att det här felet kan genereras är att programmet har fastnat i en loop eller gjort för många tokenbegäranden på kort tid. När detta inträffar kan identitetsleverantören strypa efterföljande förfrågningar under en kort tid, vilket gör att du inte omdirigeras tillbaka till din redirectUri och i slutändan leder till det här felet.

✔️ För att lösa begränsningsbaserade problem har du två alternativ:

Sluta göra begäranden under en kort tid innan du försöker igen.
Anropa ett interaktivt API, till exempel acquireTokenPopup eller acquireTokenRedirect.

X-Frame-Options Neka

Du kan också få det här felet om identitetsprovidern inte kan omdirigera tillbaka till ditt program. I scenarier utan användarinteraktion åtföljs det här felet ibland av felmeddelandet X-Frame-Options: Deny, vilket tyder på att din identitetsleverantör antingen försöker visa ett felmeddelande eller förväntar sig interaktion.

✔️ X-Frame-Options-felet har vanligtvis en URL i den och om du öppnar den här url:en på en ny flik kan det hjälpa dig att urskilja vad som händer. Om interaktion krävs bör du i stället använda ett interaktivt API. Om ett fel visas, åtgärda felet.

Vissa B2C-flöden förväntas utlösa det här felet på grund av deras behov av användarinteraktion. Dessa flöden omfattar:

Återställning av lösenord
Profilredigering
Registrera dig
Vissa anpassade principer beroende på hur de konfigureras

Svarstid för nätverk

En annan möjlig orsak till att identitetsprovidern kanske inte omdirigerar tillbaka till ditt program i tid kan vara att det finns en viss extra nätverksfördröjning.

✔️ Standardtimeouten är cirka 10 sekunder och bör i de flesta fall vara tillräcklig, men om din identitetsprovider tar längre tid än så för att omdirigera kan du öka den här tidsgränsen i MSAL-konfigurationen med antingen iframeHashTimeoutkonfigurationsparametrarna eller windowHashTimeoutloadFrameTimeout .

const msalConfig = {
    auth: {
        clientId: "your-client-id",
    },
    system: {
        windowHashTimeout: 9000, // Applies just to popup calls - In milliseconds
        iframeHashTimeout: 9000, // Applies just to silent calls - In milliseconds
        loadFrameTimeout: 9000, // Applies to both silent and popup calls - In milliseconds
    },
};

hash_empty_error

Felmeddelanden:

Det går inte att bearbeta hash-värdet eftersom det är tomt. Kontrollera att din redirectUri inte rensar hashen.

Det här felet uppstår när sidan som du använder när din redirectUri tar bort hashen eller automatiskt omdirigerar till en annan sida. Detta händer oftast när programmet implementerar en router som navigerar till en annan väg och släpper hashen.

För att lösa det här felet rekommenderar vi att du använder en dedikerad redirectUri-sida som inte omfattas av routern. För tysta och popup-anrop är det bäst att använda en tom sida. Om detta inte är möjligt kontrollerar du att routern inte navigerar medan MSAL-tokenanskaffning pågår. Du kan göra detta genom att avgöra om din applikation har lästs in i en iframe för tysta anrop, i ett popup-fönster för popup-anrop eller genom att invänta handleRedirectPromise vid omdirigeringsanrop.

hash innehåller inte kända egenskaper

Felmeddelanden:

Hash innehåller inte kända properites. Kontrollera att din redirectUri inte ändrar hashen.

Se förklaringen för hash_empty_error ovan. Grundorsaken till det här felet är densamma; skillnaden är att hashen har ändrats i stället för att ha tagits bort.

det gick inte att hämta token från den interna plattformen

Felmeddelanden:

Det går inte att hämta token från den interna plattformen.

Det här felet uppstår när API:et acquireTokenByCode anropas med nativeAccountId i stället för code och appen körs i en miljö som inte hämtar token från den inbyggda förmedlaren. En lista över förutsättningar finns i dokumentet om enhetsbundna token.

native_connection_not_established

Felmeddelanden:

Anslutningen till den interna plattformen har inte upprättats. Installera ett kompatibelt webbläsartillägg och kör initialize().

Det här felet uppstår när användaren har loggat in med den inbyggda brokerkomponenten men det för närvarande inte finns någon anslutning till den inbyggda brokerkomponenten. Detta kan hända av följande skäl:

Tillägget Windows-konton avinstallerades eller inaktiverades
API:et initialize har inte anropats eller väntades inte innan ett annat MSAL-API anropades

oinitierat offentligt klientprogram

Felmeddelanden:

Du måste anropa och invänta initieringsfunktionen innan du försöker anropa något annat MSAL-API.

Det här felet utlöses när ett login, acquireToken eller handleRedirectPromise API anropas innan API:et initialize har anropats. API:et initialize måste anropas och inväntas innan du försöker hämta token.

❌ Följande exempel genererar det här felet eftersom handleRedirectPromise anropas innan initieringen har slutförts:

const msalInstance = new PublicClientApplication({
    auth: {
        clientId: "your-client-id",
    },
    system: {
        allowNativeBroker: true,
    },
});

await msalInstance.handleRedirectPromise(); // This will throw
msalInstance.acquireTokenSilent(); // This will also throw

✔️ För att lösa detta bör du vänta tills initialize har slutförts innan du anropar något annat MSAL-API:

const msalInstance = new PublicClientApplication({
    auth: {
        clientId: "your-client-id",
    },
    system: {
        allowNativeBroker: true,
    },
});

await msalInstance.initialize();
await msalInstance.handleRedirectPromise(); // This will no longer throw this error since initialize completed before this was invoked
msalInstance.acquireTokenSilent(); // This will also no longer throw this error

Other

Fel som inte utlöses av msal, till exempel serverfel

Åtkomst till att hämta på [url] har blockerats av CORS-principen

Det här felet uppstår med MSAL.js v2.x och beror på felaktig konfiguration under appregistrering på Azure Portal. I synnerhet bör du se till att din redirectUri är registrerad som typ: Single-page application under bladet Autentisering i din appregistrering. Om det lyckas visas en grön bockmarkering som säger:

Din omdirigerings-URI är berättigad till auktoriseringskodflödet med PKCE.

bild

Feedback

Var den här sidan till hjälp?

Last updated on 2026-07-02

Errors

Konfigurationsfel för webbläsarautentisering

simulerad_offentlig_klientapplikation_anropad

BrowserAuthErrors

Interaktion_pågår

Använda loginPopup eller acquireTokenPopup

Använda loginRedirect eller acquireTokenRedirect

Wrapper-bibliotek

Felsökningssteg

block_iframe_reload

monitor_window_timeout

Problem som orsakas av redirectUri-sidan

Problem som orsakas av identitetsprovidern

Throttling

X-Frame-Options Neka

Svarstid för nätverk

hash_empty_error

hash innehåller inte kända egenskaper

det gick inte att hämta token från den interna plattformen

native_connection_not_established

oinitierat offentligt klientprogram

Other

Åtkomst till att hämta på [url] har blockerats av CORS-principen

Feedback

Ytterligare resurser

Använda `loginPopup` eller `acquireTokenPopup`

Använda `loginRedirect` eller `acquireTokenRedirect`