OAuth inne i en VPN: vilka ben som fortfarande kräver TLS

Privat routning avgör vem som når servern; OAuths transportregler avgör hur varje meddelande reser. En webbläsare, en auktoriseringsserver, en token-slutpunkt och en resursserver kan alla sitta bakom samma VPN och ändå utbyta meddelanden över olika ben. Varje ben har sitt eget transportkrav, och VPN:en lättar inte på något av dem. VPN-gränsen och protokollgränsen är två olika linjer.

Beslutet är enklare om du slutar fråga om nätverket är betrott och börjar fråga vilket utbyte som korsar vilken gräns.

Avgör per ben, inte per nätverk

Skriv ned slutpunkterna var för sig: auktoriseringsslutpunkt, token-slutpunkt, omdirigerings-URI, URL till resursservern, TLS-avslutningspunkt och VPN-gateway. Markera sedan vilken part som startar varje begäran och vart svaret går.

En VPN som slutar vid en gateway krypterar sträckan fram till den gatewayen. Begäran kan fortsätta som vanlig HTTP bakom den, och det återstående benet har inte blivit HTTPS för att en tidigare sträcka krypterades. Just den fortsättningen är det ben som protokollet bryr sig om. Att kryptera första hoppet gör inte andra hoppet säkert.

Transporten bär också en kontroll av tjänstens identitet. Webbläsaren validerar certifikatet för applikationens URL; en VPN utför inte den valideringen å webbläsarens vägnar och gör inte en ovaliderad slutpunkt acceptabel. Certifikatet namnger den slutpunkt som klienten tror att den anropar. En tunnel till en gateway byter inte namn på den slutpunkten och validerar den inte.

Auktoriseringssvaret och omdirigerings-URI:n

OAuths nuvarande bästa säkerhetspraxis förbjuder att auktoriseringssvar skickas över okrypterade anslutningar. Det omfattar omdirigeringen som bär auktoriseringskoden eller tokens tillbaka till klienten, inte bara den första begäran.

Samma vägledning tillåter inte HTTP-omdirigerings-URI:er, utom det angivna loopback-fallet för inhemska klienter. Ett internt värdnamn skapar inte ett nytt undantag, och ett DNS-namn som bara löses inne i VPN:en är fortfarande en HTTP-URL om schemat säger det. Kontrollera schemat i den registrerade URI:n, inte bara värdnamnet.

Registrera den exakta HTTPS-omdirigerings-URI:n hos auktoriseringsservern och håll certifikatvalideringen påslagen i klienten. En utvecklingsgenväg som undertrycker HTTPS-kravet ger ett flöde som beter sig annorlunda än den produktionskonfiguration som den ska modellera.

Token-slutpunkten och begäranden med bärar-token

Tokenbegäran bär autentiseringsuppgifter eller en kod som kan bytas mot åtkomst. Att skicka den över ett oskyddat ben blottar material som resursservern senare kommer att lita på, även om nätverket runtom är privat. En proxy som kan läsa begäran kan också läsa de autentiseringsuppgifter som den bär.

För resursbegäranden med bärar-token behandlar RFC 6750 TLS som obligatoriskt att implementera och använda för den specifikationen. Att kalla kontorets subnät betrott är inte det allmänna protokollundantag som en bärar-distribution i klartext behöver.

Använd de dokumenterade säkra slutpunkts-URL:erna för båda benen. Om ett bibliotek vägrar anropa en HTTP-token-slutpunkt är den vägran specifikationen som fungerar, inte ett konfigurationsfel att kringgå. Skriv den URL:en i klientkonfigurationen i stället för att härleda den vid körning.

Var TLS slutar och vad det lämnar

Om TLS slutar vid en auktoriserad frontend, namnge den frontenden och granska vägen från den till applikationen. Frontenden blir ansvarig för vidarebefordran, förtroende och konfidentialitet på den återstående sträckan, och tjänstens stödda arkitektur bör beskriva den ordningen.

En VPN någon annanstans på vägen avgör inte de ansvarsförhållandena. Den säger inte heller om applikations-URL:en som webbläsaren ser motsvarar det certifikat som frontenden presenterar.

För en intern distribution, registrera avslutningspunkten och den identitet som den presenterar. En frontend som avslutar TLS med ett certifikat för ett annat namn skapar en webbläsarvarning som operatörer ofta undertrycker i stället för att åtgärda.

Undantaget för inhemsk loopback är smalt

Undantaget för loopback-omdirigering gäller en återkallelse på användarens egen enhet, där klienten och webbläsaren delar den enheten. Den ordningen tillhör en återkallelse på en enhet och ger ingen licens att betjäna en vanlig auktoriseringsserver eller ett API med tokens över HTTP till ett kontorssubnät.

Håll undantaget begränsat till klienttypen och den återkallelse som det beskriver. Att tillämpa det på en webbapplikation, en delad intern tjänst eller en omdirigerings-URI på en annan värd ändrar distributionen, inte undantaget.

Testa det faktiska flödet vid varje gräns och jämför det med klienttypen. En fungerande omdirigering säger ingenting om huruvida varje ben som bar en token använde det krävda skyddet, och en grön VPN-ikon säger ingenting om schemat för nästa begäran.