Hur man använder Fiddler för att felsöka autentiseringsflöden

Fiddler från Telerik är ett kraftfullt verktyg som används för att övervaka och analysera HTTP-nätverkstrafik.

Placerad mellan webbservern och klientapplikationen fungerar den som en webbproxy. Så alla HTTP(S)-förfrågningar dirigeras genom Fiddler innan de fortsätter till sina destinationer. På samma sätt återvänder HTTP(S)-svar endast till den anropande applikationen efter att först ha passerat genom Fiddler. Som ett resultat får vi ett omfattande spår av all webbtrafik på en viss maskin.

Fiddler är utomordentligt användbart för felsökning och testning. Det är också helt teknikagnostiskt och kan användas för webb-, skrivbords- och mobilapplikationer.

Föga förvånande är Fiddler mycket praktiskt för felsökning av autentiseringsflöden.

Det är vad dagens inlägg handlar om. Här är vad vi kommer att täcka:

• Hur man tolkar nätverksspårningen
• Vad man kan förvänta sig i ett korrekt konfigurerat autentiseringsflöde
• Vanliga fallgropar som kan kräva uppmärksamhet.

Vi hoppas att detta hjälper utvecklare att felsöka problem när de implementerar federerad autentisering med OpenID Connect via Idura.

Vi kommer att använda Fiddler Everywhere för Mac, men Windows-användare kan få samma funktionalitet med Fiddler Classic.

Grunderna i ett federerat autentiseringsflöde

Federerade autentiseringsflöden involverar alltid tre parter:

1. Identitetsleverantören (IdP)
2. Relying Party (den anropande applikationen)
3. Användaragent (t.ex. en webbläsare)

När problem uppstår är den svåraste delen ofta att avgöra vilken av de tre som är ansvarig. Fiddler kan hjälpa till med detta genom att tillhandahålla ett detaljerat register över interaktioner mellan de tre enheterna.

Den specifika sekvensen av interaktioner i autentiseringsprocessen beror på vilket protokoll som används. I vårt fall är det OAuth2 och OpenID Connect. Den valda bidragstypen (Authorization Code flow eller PKCE) kommer också att införa små variationer.

1. Beviljande av auktoriseringskod

I denna grant gör användarens webbläsare en authorize-begäran till webbapplikationen och får en auktoriseringskod i retur. Webbapplikationen kontaktar sedan Identity Providern för att byta ut auktoriseringskoden mot en token.

Den här typen av auktorisering används vanligtvis i traditionella serverbaserade applikationer och innebär exekvering på serversidan. För att fånga en fullständig nätverksspårning bör Fiddler därför köras på den server som utför autentiseringen (vi kommer att demonstrera detta senare i artikeln).

2. PKCE

PKCE är en utökning av Authorization Code grant och introducerar ytterligare ett säkerhetslager och är erkänt som den bästa metoden för att implementera autentisering i publika klienter, t.ex. mobila applikationer och applikationer med en enda sida.

I det här flödet ingår en unik hemlighet, en så kallad "kodverifierare", i auktoriseringsbegäran. Auktoriseringsservern svarar med en kodutmaning - en hashad version av kodverifieraren. För att få en token måste klienten tillhandahålla både koden och kodverifieraren under utbytet av kod mot token.

Om ditt program använder PKCE för autentisering kommer du att se en code_verifier-parameter i API-anropet när kodutbytet utförs.

Komma igång med Fiddler

Om du inte känner till Fiddler sedan tidigare finns här en enkel guide som hjälper dig att komma igång.

Fånga HTTPS-trafik

Som standard fångar Fiddler endast icke-säker HTTP-trafik, exklusive krypterade HTTPS-förfrågningar.

Eftersom den mesta trafiken nuförtiden är HTTPS, kommer du sannolikt att vilja konfigurera Fiddler för att dekryptera den. Du kan uppnå detta genom att antingen:

• Installera Fiddlers rotcertifikat på din dator: Följ stegen som beskrivs i den officiella guiden för att göra det.
• Använda en förkonfigurerad Browser Capturing-funktion: Detta kräver inga extra konfigurationer.

När du har valt det alternativ som passar dig bäst är du redo att inspektera autentiseringsflödet.

Starta Fiddler Capture

1. Starta Fiddler överallt.
2. Aktivera System Proxy-omkopplaren (om du har Fiddler-rotcertifikatet betrott) eller använd webbläsarens Capturing-läge.
   
   
   
   
3. Navigera till din app eller webbplats och kör autentiseringsflödet. Fiddler-konsolen kommer att visa alla webbläsaråtgärder som är involverade i autentiseringsflödet, så att du kan inspektera varje begäran och svar.
4. När du har slutfört autentiseringsflödet stänger du av System Proxy-omkopplaren (om den var aktiverad).
5. Du kan nu inspektera den infångade nätverksspårningen.

Den lyckliga vägen

Låt oss analysera en nätverksspårning av en enkel React-applikation som låter en användare logga in med en elektronisk identitet (eID). Vi kommer att använda Cool Energy-demo-appen för demonstration.

Följ med om du vill!

Låt oss börja med att starta Fiddler. Vi kommer att utnyttja webbläsarfunktionen för att isolera nätverksspårningen till en specifik webbläsarprocess. I det nyöppnade webbläsarfönstret navigerar du till appen: https://demo-cool-energy-react.netlify.app/.

Vi ska nu agera som en slutanvändare och logga in med ett eID.

Nedan följer en detaljerad uppdelning av processen, tillsammans med ett nätverksspår som fångats av Fiddler.

Obs: Vi tillämpar filter för att visa de förfrågningar som är relevanta för autentiseringsflödet. Om du följer med kommer du att se ytterligare förfrågningar (t.ex. teckensnittsfiler, bilder etc.)

1. Vi navigerar till inloggningssidan för applikationen och initierar sedan inloggningsprocessen genom att välja ett eID-alternativ. Vi kommer att använda MitID. Knappen "Logga in med MitID" tar oss till URL:en för auktorisering med en uppsättning parametrar.
   
   Obs: URL:er för auktorisering följer denna struktur: /oauth2/authorize
   
   
2. Vi slutför autentiseringen med MitID (med hjälp av en MitID-testanvändare). Detta utlöser flera förfrågningar till Identity Provider, inklusive anrop till pp.mitid.dk och criipto.pp.mitid.dk*.
   
   
3. Efter en lyckad autentisering omdirigeras vi tillbaka till vår domän hos Idura:
   https://demos-test.criipto.id/DKMitId/Callback?cs_v1=c6b279940d324c81977c367bd49ed0ae&code=40d0c7dd-d574-45eb-89d2-f5d9b075d1a2
   
   
   
   
4. En annan omdirigering tar oss till klientapplikationens URL för återuppringning. Lägg märke till kodparametern: Detta är auktoriseringskoden. https://demo-cool-energy-react.netlify.app/login?code=7f4959d095164568a1c6ac52d58947ee
   
   
5. Auktoriseringskoden byts sedan ut mot en id_token. Detta görs genom att skicka koden från föregående steg till token-slutpunkten: leta efter /oauth2/token-begäran i nätverksspårningen.
   
   Om du inspekterar begärans kropp i Fiddler-konsolen hittar du en code_verifier bland andra parametrar. Detta indikerar ett PKCE-flöde.
   
   
6. Efter ett framgångsrikt utbyte av kod mot token är autentiseringen slutförd.
   Användaren är nu inloggad (och omdirigeras till instrumentpanelen), medan applikationen har tillgång till användarens information i form av JWT-anspråk.

Felsökning av autentiseringsfel

Det kan vara utmanande att förstå och lösa autentiseringsfel, med tanke på att autentiseringsimplementeringar i den verkliga världen ofta är mycket mer invecklade än den grundläggande React SPA från vårt genomgång.

Lyckligtvis kan en nätverksspårning verkligen hjälpa till när problemkällan inte är omedelbart uppenbar.

Låt oss titta på tre vanliga problem som leder till autentiseringsfel, tillsammans med motsvarande poster från nätverksspårningen.

1. Felaktig hantering av sessioner

Felaktig sessionshantering inom klientapplikationen är en vanlig stötesten i autentiseringsimplementeringar. Sessioner som inte hanteras korrekt kan t.ex. resultera i en redirect-loop.

Tänk dig ett scenario med en Node.js + Express-applikation där åtkomsten till /profile-rutten är begränsad till autentiserade användare. Oautentiserade användare omdirigeras för att starta en inloggning.

Låt oss anta att en id_token hämtas efter att en användare loggar in med ett eID och används för att skapa en session på servern med express-session.

Mellanvaran kontrollerar om användaren är inloggad, men det finns ett förbiseende i en annan del av koden: Användarens uppgifter sparas inte i sessionen.

// app.js
const expressSession = require('express-session');
…
// Middleware to check if the user is logged in
const isLoggedIn = (req, res, next) => {
  if (req.session && req.session.user) {
    // User is logged in, continue to the next middleware or route handler
    next();
  } else {
    // User is not logged in, redirect to login
    res.redirect(
`https://${IDURA_DOMAIN}/oauth2/authorize?scope=openid&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Flogin%2Fcallback&client_id=urn%3Ademos%3Acool-energy-react`
    );	
  }
};

app.get('/login/callback', async (req, res) => {
  // Assuming authentication is successful
  const idToken = await getToken();
  const authenticatedUser = {
    // user information from idToken here
  };

  // Forgetting to save user information in a session
  //req.session.user = authenticatedUser;
  res.redirect('/profile');
});

app.get('/profile', isLoggedIn, (req, res) => {
  const { user } = req.session;
  res.render('profile', { user });
});

Som ett resultat omdirigeras användare till inloggningssidan efter att ha försökt komma åt /profile-rutten.

En Fiddler-spårning skulle visa ett kod-för-token-utbyte som indikerar framgångsrik autentisering, följt av en omdirigering till URL:en för auktorisering (som representerar /login-rutten ).

Om Single Sign-On (SSO) är aktiverat för din domän kan det här scenariot dessutom resultera i en omdirigeringsloop som leder till ett 429-fel.

För att åtgärda detta måste du säkerställa korrekt sessionshantering i din applikation (och komma ihåg att implementera kontroller för tokenutgång).

2. Kod-för-token-utbyte utförs inte korrekt

Iduras SDK:er kommer att hantera kod-för-token-utbytet åt dig. Vi rekommenderar generellt att man väljer ett pålitligt bibliotek som kan hantera denna uppgift. Men naturligtvis kan du utforska möjligheten att bygga din egen lösning.

Om du gör det kommer du att märka att anropet för att byta ut auktoriseringskoden mot en token måste innehålla följande parametrar:

code = Auktoriseringskod
client_id = <id för klientapplikationen>
redirect_uri = <URL dit auktoriseringskoden ska returneras>.
grant_type = auktoriseringskod

Du måste se till att:

• client_id och redirect_uri är korrekta
• Auktoriseringskoden inte har använts tidigare (varje kod är giltig för en enda användning).
• Auktoriseringskoden inte har löpt ut (de har vanligtvis en kort livslängd).

Låt oss använda Node.js + Express-applikationen från vårt tidigare exempel.

Den här gången, säg, glömmer vi att skicka klientens referenser tillsammans med begäran:

const codeExchange = async (authorizationCode) => {
  const tokenEndpoint = `${IDURA_DOMAIN}/oauth2/token`;

// Encode client credentials for authorization header
  const credentials = base64.encode(`${CLIENT_ID}:${CLIENT_SECRET}`);

  try {
    const response = await axios.post(tokenEndpoint,
      {
        code: authorizationCode,
        redirect_uri: 'http://localhost:3000/callback',
        grant_type: 'authorization_code',
      },
//     {
//        headers: {
//       Authorization: `Basic ${credentials}`,
//         'Content-Type': 'application/x-www-form-urlencoded',
//        },
//      }
    );

    const accessToken = response.data.access_token;
    console.log(`Successfully exchanged code for access token: ${accessToken}`);
    return accessToken;
  } catch (error) {
    console.error('Error exchanging code for token');
    throw error;
  }
};

I Fiddler-spåret ser vi att kod-för-token-utbytet inte har utförts framgångsrikt:

* Detta spår spelades in med hjälp av Fiddlers Terminal Tracing-läge. Eftersom appen implementerar Authorization code grant bör nätverksspårningen spelas in på den server som utför autentisering för att kodutbytet ska visas i nätverksspårningen.

3. Flera kodutbyten

Ett kod-för-token-utbyte bör endast utföras en gång för lyckad autentisering.

Om autentiseringen misslyckas och du inte omedelbart kan hitta rotorsaken kan du kontrollera att det bara finns ett anrop till token-slutpunkten. Leta efter en URL med den här sökvägen i nätverksspårningen: /oauth2/token.

Nedan finns ett exempel på en Fiddler-spårning som visar problemet. Följande kan hända när man använder Iduras React-bibliotek i StrictMode.

* Detta är fallet då vi exekverar sidoeffekter i useEffect. För att åtgärda detta, vänligen flytta StrictMode ner i trädet så att det ligger inuti IduraVerifyProvider:

// index.js
<CriiptoVerifyProvider>
  <React.StrictMode>
    <App />
  </React.StrictMode>
</CriiptoVerifyProvider>

* Problemet har åtgärdats i version 2.0.2.

Avslutning

Vi har täckt några vanliga problem, men det finns mycket mer att utforska inom felsökning av autentisering.

Så om du stöter på utmaningar eller har insikter att dela, tveka inte att nå ut.

Vi uppskattar verkligen din feedback!

Criipto är nu Idura!

Du kanske stöter på criipto i våra domännamn och kodprover. Detta är väntat eftersom vi har bytt namn!

Läs om namnbytet här.