Slik bruker du Fiddler til å feilsøke autentiseringsprosesser

Fiddler fra Telerik er et kraftig verktøy som brukes til å overvåke og analysere HTTP-nettverkstrafikk.

Verktøyet er plassert mellom webserveren og klientapplikasjonen, og fungerer som en webproxy. Alle HTTP(S)-forespørsler rutes gjennom Fiddler før de går videre til destinasjonen. På samme måte returnerer HTTP(S)-svar bare til den anropende applikasjonen etter først å ha passert gjennom Fiddler. Resultatet er at vi får en omfattende oversikt over all nettrafikk på en gitt maskin.

Fiddler er svært nyttig for feilsøking og testing. Den er også fullstendig teknologi-agnostisk og kan brukes til web-, desktop- og mobilapplikasjoner.

Ikke overraskende er Fiddler veldig nyttig for feilsøking av autentiseringsflyter.

Det er det dette innlegget handler om. Her er hva vi skal gå gjennom:

• Hvordan tolke nettverkssporing
• Hva du kan forvente i en korrekt konfigurert autentiseringsflyt
• Vanlige fallgruver som kan kreve oppmerksomhet.

Vi håper dette hjelper utviklere med å feilsøke problemer når de implementerer sammenkoblet autentisering med OpenID Connect via Idura.

Vi bruker Fiddler Everywhere for Mac, men Windows-brukere kan få samme funksjonalitet med Fiddler Classic.

Grunnleggende om føderert autentiseringsflyt

En sammenkoblet autentiseringsflyt involverer alltid tre parter:

1. Identitetsleverandøren (IdP)
2. Den avhengige part (den anropende applikasjonen)
3. Brukeragenten (f.eks. en nettleser)

Når det oppstår problemer, er det vanskeligste ofte å finne ut hvem av de tre som er ansvarlig. Fiddler kan være til stor hjelp med dette ved å gi en detaljert oversikt over interaksjonene mellom de tre enhetene.

Den spesifikke sekvensen av interaksjoner i autentiseringsprosessen avhenger av hvilken protokoll som brukes. I vårt tilfelle er det OAuth2 og OpenID Connect. Den valgte typen godkjenning (Authorization Code flow eller PKCE) vil også introdusere små variasjoner.

1. Tildeling av autorisasjonskode

I denne tildelingen sender brukerens nettleser en autorisasjonsforespørsel til webapplikasjonen og mottar en autorisasjonskode i retur. Webapplikasjonen kontakter deretter identitetsleverandøren for å utveksle autorisasjonskoden mot et token.

Denne typen autorisasjon brukes vanligvis i tradisjonelle serverbaserte applikasjoner, og innebærer kjøring på serversiden. For å fange opp en fullstendig nettverkssporing bør Fiddler derfor kjøre på serveren som utfører autentiseringen (vi demonstrerer dette senere i artikkelen).

2. PKCE

PKCE er en utvidelse av Authorization Code grant, og introduserer et ekstra sikkerhetslag og er anerkjent som den beste praksisen for å implementere autentisering i offentlige klienter, for eksempel mobil- og enkeltsidesapplikasjoner.

I denne flyten innlemmes en unik hemmelighet, kjent som en "kodeverifiserer", i autorisasjonsforespørselen. Autorisasjonsserveren svarer med en kodeutfordring - en hashet versjon av kodeverifikatoren. For å få et token må klienten oppgi både koden og kodeverifikatoren under utvekslingen av kode for token.

Hvis applikasjonen din bruker PKCE for autentisering, vil du se en code_verifier-parameter i API-kallet når kodeutvekslingen utføres.

Komme i gang med Fiddler

Hvis du er ny i Fiddler, får du her en enkel veiledning for å komme i gang.

Registrering av HTTPS-trafikk

Som standard fanger Fiddler bare opp ikke-sikker HTTP-trafikk, unntatt krypterte HTTPS-forespørsler.

Siden det meste av trafikken i dag er HTTPS, vil du sannsynligvis ønske å konfigurere Fiddler til å dekryptere den. Du kan oppnå dette ved å enten:

• Installere Fiddlers rotsertifikat på maskinen din: Følg trinnene i den offisielle veiledningen for å gjøre dette.
• Bruke en forhåndskonfigurert funksjon for registrering i nettleseren: Dette krever ingen ekstra konfigurasjoner.

Når du har valgt det alternativet som passer deg best, er du klar til å inspisere autentiseringsflyten.

Starte Fiddler Capture

1. Start Fiddler Everywhere.
2. Aktiver System Proxy-bryteren (hvis du har Fiddler-rotsertifikatet klarert) eller bruk nettleserregisteringsmodus.
   
3. Naviger til appen eller nettstedet ditt, og kjør autentiseringsflyten. Fiddler-konsollen vil vise alle nettleserhandlingene som er involvert i autentiseringsflyten, slik at du kan inspisere hver forespørsel og hvert svar.
4. Når du har fullført autentiseringsflyten, slår du av System Proxy-bryteren (hvis den var aktivert).
5. Du kan nå inspisere den registrerte nettverkssporingen.

Den lykkelige stien

La oss analysere et nettverksspor av en enkel React-applikasjon som lar en bruker logge inn med en elektronisk identitet (eID). Vi bruker Cool Energy-demoappen for demonstrasjon.

Følg med hvis du vil!

La oss starte med å starte Fiddler. Vi bruker nettleserfunksjonen til å isolere nettverkssporing til en spesifikk nettleserprosess. I det nyåpnede nettleservinduet navigerer du til appen: https://demo-cool-energy-react.netlify.app/.

Vi skal nå opptre som en sluttbruker og logge inn med en eID.

Nedenfor følger en detaljert oversikt over prosessen, ledsaget av en nettverkssporing fanget opp av Fiddler.

Merk: Vi bruker filtre for å vise forespørslene som er relevante for autentiseringsflyten. Hvis du følger med, vil du se flere forespørsler (f.eks. fontfiler, bilder osv.)

1. Vi navigerer til påloggingssiden i applikasjonen, og starter deretter påloggingsprosessen ved å velge et eID-alternativ. Vi velger MitID. Knappen "Logg inn med MitID" tar oss til autorisasjons-URL-en med et sett med parametere.
   
   Merk: URL-adresser for autorisering følger denne strukturen: /oauth2/authorize
   
   
2. Vi fullfører autentiseringen med MitID (ved hjelp av en MitID-testbruker). Dette utløser flere forespørsler til Identity Provider, inkludert anrop til pp.mitid.dk og criipto.pp.mitid.dk*.
   
   
3. Etter vellykket autentisering blir vi omdirigert tilbake til domenetvårt hos Idura:
   https://demos-test.criipto.id/DKMitId/Callback?cs_v1=c6b279940d324c81977c367bd49ed0ae&code=40d0c7dd-d574-45eb-89d2-f5d9b075d1a2
   
   
   
   
4. En annen viderekobling tar oss til tilbakekallingsadressen til klientapplikasjonen. Legg merke til kodeparameteren: Dette er autorisasjonskoden. https://demo-cool-energy-react.netlify.app/login?code=7f4959d095164568a1c6ac52d58947ee
   
   
5. Autorisasjonskoden byttes deretter ut mot en id_token. Dette gjøres ved å sende koden fra forrige trinn til token-sluttpunktet: Se etter /oauth2/token-forespørselen i nettverkssporet.
   
   Hvis du inspiserer forespørselsteksten i Fiddler-konsollen, vil du finne en code_verifier blant andre parametere. Dette indikerer en PKCE-flyt.
   
   
6. Etter en vellykket kode-for-token-utveksling er autentiseringen fullført.
   Brukeren er nå innlogget (og omdirigert til dashbordet), mens applikasjonen har tilgang til brukerens informasjon i form av JWT-påstander.

Feilsøking av autentiseringsfeil

Det kan være utfordrende å forstå og løse autentiseringsfeil, siden autentiseringsimplementeringer i den virkelige verden ofte er langt mer kompliserte enn den grunnleggende React SPA-en fra gjennomgangen vår.

Heldigvis kan en nettverkssporing være til stor hjelp når problemkilden ikke er umiddelbart åpenbar.

La oss se på tre vanlige problemer som fører til autentiseringsfeil, sammen med tilsvarende poster fra nettverkssporing.

1. Feilaktig håndtering av økter

Feilaktig økthåndtering i klientapplikasjonen er en vanlig snublestein i autentiseringsimplementeringer. Sesjoner som ikke håndteres korrekt, kan f.eks. føre til en omdirigeringssløyfe.

Tenk deg et scenario med en Node.js + Express-applikasjon der tilgangen til /profile-ruten er begrenset til autentiserte brukere. Uautentiserte brukere blir omdirigert for å starte en innlogging.

La oss anta at en id_token hentes etter at en bruker logger på med en eID og brukes til å opprette en økt på serveren med express-session.

Kontrollkomponent (middleware) sjekker om brukeren er innlogget, men det er en forglemmelse i en annen del av koden: Brukerens opplysninger blir ikke lagret i økten.

// 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 });
});

Resultatet er at brukerne blir omdirigert til påloggingssiden etter å ha forsøkt å gå til /profile-ruten.

En Fiddler-sporing vil vise en kode-for-token-utveksling som indikerer vellykket autentisering, etterfulgt av en omdirigering til URL-adressen for autorisering (som representerer /login-ruten ).

Hvis Single Sign-On (SSO) er aktivert for domenet ditt, kan dette scenariet i tillegg resultere i en omdirigeringssløyfe som fører til en 429-feil.

For å løse dette må du sørge for riktig øktadministrasjon i applikasjonen (og huske å implementere kontroller for utløp av tokener).

2. Kode-for-token-utveksling utføres ikke korrekt

Iduras SDK-er håndterer kode-for-token-utvekslingen for deg. Vi anbefaler generelt å velge et pålitelig bibliotek som kan håndtere denne oppgaven. Men du kan selvfølgelig også utforske muligheten for å bygge din egen løsning.

Hvis du gjør det, vil du legge merke til at kallet for å bytte ut autorisasjonskoden mot et token må inneholde følgende parametere:

code = Autorisasjonskode
client_id = <id for klientapplikasjonen>
redirect_uri = <URL der autorisasjonskoden skal returneres til>
grant_type = autorisasjonskode

Du må sørge for at:

• client_id og redirect_uri er korrekte
• Autorisasjonskoden ikke har blitt brukt før (hver kode er gyldig for én gangs bruk).
• Autorisasjonskoden ikke er utløpt (de har vanligvis kort levetid).

La oss bruke Node.js + Express-applikasjonen fra forrige eksempel.

Denne gangen glemmer vi å sende klientlegitimasjonen sammen med forespørselen:

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-sporet ser vi at kode-for-token-utvekslingen ikke har blitt utført:

* Denne sporingen ble registrert ved hjelp av Fiddlers Terminal Tracing-modus. Siden appen implementerer Authorization code grant, bør nettverkssporet registreres på serveren som utfører autentisering for at kodeutvekslingen skal vises i nettverkssporet.

3. Flere kodeutvekslinger

En kode-for-token-utveksling skal bare utføres én gang for vellykket autentisering.

Hvis autentiseringen mislykkes og du ikke umiddelbart kan finne årsaken, kan det være lurt å sjekke at det bare er ett kall til token-sluttpunktet. Se etter en URL med denne banen i nettverkssporet: /oauth2/token.

Nedenfor er et eksempel på en Fiddler-sporing som demonstrerer problemet. Følgende kan skje når du bruker Iduras React-bibliotek i StrictMode.

* Dette er tilfelle når vi utfører sideeffekter i useEffect. For å løse dette kan du foreløpig flytte StrictMode nedover i treet, slik at den er inne i IduraVerifyProvider:

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

* Problemet er løst i versjon 2.0.2.

Oppsummering

Vi har dekket noen vanlige problemer, men det finnes mye mer å utforske innen feilsøking av autentisering.

Så hvis du støter på utfordringer eller har innsikt å dele, ikke nøl med å ta kontakt.

Vi setter stor pris på tilbakemeldingene dine!