fixed links

Author: jksolbakken

content/posts/oauth-del3-pkce.md

@@ -13,15 +13,15 @@ tags: ["oauth", "oidc", "sikkerhet"]
 
 Dette er del 3 i serien om OAuth og OIDC. Den mest brukte OAuth-flyten, "Authorization Code flow", innebærer at `client` og `id provider` utveksler hemmeligheter. Klienten må derfor være i stand til å holde på hemmelig informasjon på en trygg måte, i standarden omtales dette som `confidential clients`. For mobil-apps og "single page" webapplikasjoner har dette ikke vært gjennomførbart da hemmelighetene må distribueres helt ut til sluttbrukeren som en del av appen.
 
-I [del 1](/posts/oauth1) ble standarden og terminologien gjennomgått, ta en titt på den hvis du trenger en innføring eller oppfriskning.
+I [del 1](/blog/posts/oauth1) ble standarden og terminologien gjennomgått, ta en titt på den hvis du trenger en innføring eller oppfriskning.
 
 Authorization Code flow har også en svakhet som kalles "authorization code injection". Et slikt angrep er komplisert å gjennomføre og krever at mange ting skal klaffe samtidig, men er ingen umulighet. Dersom noen som har stjålet din `client_id` og `client_secret` klarer å fange opp en authorization code kan de gjøre et token-kall på dine vegne, og dermed utgi seg for den aktuelle sluttbrukeren. Hvordan klarer man så å fange opp en authorization code? Callbacks gjøres jo kun til (forhåpentligvis) forhåndsgodkjente URLer over HTTPS? Vel, ikke alltid. En måte er å utnytte custom "URL schemes" på telefoner. En telefon-app vil typisk registrere callback URLs av type `myapp://something`, dette gjør at kallene rutes til denne appen. Hvis en angriper får deg til å installere en app som registrerer seg som lytter på myapp-URLs vil denne appen også få tilsendt callbackene som inneholder koden.
 
 ## PKCE
 
 For å bøte på disse svakhetene har det blitt laget et tillegg til OAuth-standarden. Tillegget beskriver teknikken "Proof Key for Code Exchange" som forkortes "PKCE" og uttales "pixie".
 
-Authorization Code flow ser ut som vist i figuren (se [del 1][del 1](/posts/oauth1) for detaljer).
+Authorization Code flow ser ut som vist i figuren (se [del 1][del 1](/blog/posts/oauth1) for detaljer).
 
 ![authorization code flow](/blog/images/auth_code.png) 
 

content/posts/oauth1.md

@@ -11,7 +11,7 @@ tags: ["oauth", "oidc", "sikkerhet"]
 
 ## Innledning
 
-Dette er del 1 av 3 om OAuth og OIDC, hva det er, hvilke problemer det løser og hvordan vi bruker det i NAV. Denne første delen forsøker å forklare og avmystifisere standardene litt. [Del 2](/blog/posts/2020/09/oauth-del-2-token-exchange.html) tar for seg den nylig standardiserte `Token Exchange`-flyten og hvordan vi har løst den med [TokenX](https://doc.nais.io/security/auth/tokenx/). [Del 3](/blog/posts/2021/03/oauth-del-3-pkce.html) handler om "Proof Key for Code Exchange", a.k.a. PKCE.
+Dette er del 1 av 3 om OAuth og OIDC, hva det er, hvilke problemer det løser og hvordan vi bruker det i NAV. Denne første delen forsøker å forklare og avmystifisere standardene litt. [Del 2](/blog/posts/oauth2) tar for seg den nylig standardiserte `Token Exchange`-flyten og hvordan vi har løst den med [TokenX](https://doc.nais.io/security/auth/tokenx/). [Del 3](/blog/posts/oauth-del3-pkce) handler om "Proof Key for Code Exchange", a.k.a. PKCE.
 
 ## Bakgrunn
 

content/posts/oauth2.md

@@ -10,7 +10,7 @@ tags: ["oauth", "oidc", "sikkerhet"]
 ![OAuth2](/blog/images/oauth2.png) 
 
 ## Bakgrunn
-I NAV er [OAuth og OIDC](/blog/posts/2020/09/oauth-del-1.html) de facto standard for å løse autentisering og autorisering i appene våre. I en løst koblet verden med mikrotjenester og [zero trust](https://doc.nais.io/appendix/zero-trust) er det imidlertid flere brikker som må på plass. Hvordan kan man på en trygg måte kalle andre tjenester videre bakover i kjeden og samtidig bevare sluttbrukerkonteksten? Tidligere har man benyttet såkalte "systembrukere", dvs brukere som identifiserer systemet/tjenesten som det kalles fra. Man har hatt en eller flere [Security Token Services](https://en.wikipedia.org/wiki/Security_token_service) som har vekslet systembrukerens brukernavn og passord inn i et access token som benyttes for videre kall. Dette har flere ulemper. Systembrukerene må ha ganske romslige rettigheter (som gjør det ekstra viktig at de ikke blir kompromittert), og informasjon om sluttbrukeren som initierte kallet blir borte med mindre man legger på hjemmesnekra hacks.
+I NAV er [OAuth og OIDC](/blog/posts/oauth1) de facto standard for å løse autentisering og autorisering i appene våre. I en løst koblet verden med mikrotjenester og [zero trust](https://doc.nais.io/appendix/zero-trust) er det imidlertid flere brikker som må på plass. Hvordan kan man på en trygg måte kalle andre tjenester videre bakover i kjeden og samtidig bevare sluttbrukerkonteksten? Tidligere har man benyttet såkalte "systembrukere", dvs brukere som identifiserer systemet/tjenesten som det kalles fra. Man har hatt en eller flere [Security Token Services](https://en.wikipedia.org/wiki/Security_token_service) som har vekslet systembrukerens brukernavn og passord inn i et access token som benyttes for videre kall. Dette har flere ulemper. Systembrukerene må ha ganske romslige rettigheter (som gjør det ekstra viktig at de ikke blir kompromittert), og informasjon om sluttbrukeren som initierte kallet blir borte med mindre man legger på hjemmesnekra hacks.
 
 ## Token Exchange standarden
 [RFC 8693 - OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693.html) adresserer akkurat dette problemet, og har nå endelig blitt en "proposed standard". Azure AD (som vi bruker som ID-provider for egne ansatte) har lenge tilbydd en [on-behalf-of flyt](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) som er veldig lik den nye standarden, men for borgerne som logger på med ID-porten har vi ikke hatt noe tilsvarende.