Sökresultat :
×Sökresultat :
×
När en användare loggar in på en Joomla-webbplats via OAuth SSO skickar identitetsleverantören tillbaka en auktoriseringskod via webbläsaren. Applikationen byter sedan ut den koden mot en åtkomsttoken. Detta fungerar bra i de flesta fall, men det finns ett problem: om någon lyckas fånga upp auktoriseringskoden innan den når applikationen kan de använda den för att själva få en åtkomsttoken.
PKCE (Proof Key for Code Exchange) förhindrar detta. Innan inloggningen startar genererar applikationen en slumpmässig hemlighet, skickar en hashad version av den till identitetsleverantören och bevisar sedan att den har originalkoden när koden utbyts mot en token. En avlyssnad auktoriseringskod är värdelös utan det beviset, eftersom bara den ursprungliga applikationen har den.
Tillägget miniOrange Joomla OAuth Client har stöd för PKCE direkt. Genom att aktivera det läggs detta säkerhetslager till i din befintliga SSO-konfiguration utan att ändra något i hur användare loggar in.
För att aktivera PKCE-skyddad OAuth SSO på en Joomla-webbplats behöver du följande:
De flesta Joomla-webbplatser som kör OAuth SSO använder standardflödet för auktoriseringskod utan PKCE. Detta är okej för många scenarier, men det skapar vissa verkliga risker som är värda att förstå.
Auktoriseringskoder passerar genom webbläsaren som URL-parametrar, vilket innebär att de kan hamna i webbläsarhistorik, serverloggar och hänvisningsrubriker. Det finns ett fönster, även om det är kort, där de exponeras. För applikationer som inte kan lagra en klienthemlighet säkert, som appar med en sida eller webbläsarbaserade SSO-flöden, blir auktoriseringskoden det enda som står mellan en användares konto och en angripare som fått tag på den.
OAuth 2.1, som återspeglar aktuella säkerhetsrutiner, gör PKCE obligatoriskt för alla auktoriseringskodflöden. Organisationer som arbetar mot att följa standarder som SOC 2 eller ISO 27001 förväntas i allt högre grad ha detta på plats.
Utan PKCE finns det inte heller några kryptografiska bevis på att klienten som slutför tokenutbytet är densamma som startade inloggningen. Den luckan gör det svårare att genomföra tydliga säkerhetsrevisioner.
Att konfigurera PKCE via miniOrange OAuth Client-tillägget är enkelt. Så här går konfigurationen till.
1. Aktivera PKCE i tillägget: I OAuth-leverantörsinställningarna i miniOrange-tillägget finns ett dedikerat alternativ för att aktivera PKCE. När det är aktiverat tar tillägget hand om allt automatiskt: det genererar en slumpmässig kodverifierare i början av varje inloggning, skapar en hashad utmaning från den och skickar den utmaningen till identitetsleverantören som en del av auktoriseringsbegäran. När tokenutbytet sker skickas den ursprungliga verifieraren tillsammans med auktoriseringskoden så att identitetsleverantören kan bekräfta att de matchar.
2. Val av kodutmaningsmetod: Tillägget stöder två metoder: S256 och plain. S256 hashar kodverifieraren med SHA-256 innan utmaningen skickas, vilket innebär att den ursprungliga hemligheten aldrig överförs. Plain-metoden skickar verifieraren direkt som utmaningen, vilket inte erbjuder något riktigt skydd. För alla aktiva Joomla-webbplatser är S256 rätt val, och de flesta moderna identitetsleverantörer stöder det.
3. Uppdatera identitetsleverantörens konfiguration: På identitetsleverantörens sida bör applikationsregistreringen uppdateras för att kräva PKCE. Detta innebär vanligtvis att markera applikationen som en offentlig klient eller aktivera PKCE-tillämpning i appinställningarna. De exakta stegen varierar beroende på leverantör. Att göra PKCE obligatoriskt på leverantörsnivå är viktigt eftersom det innebär att alla tokenutbyten som försöks utan en giltig kodverifierare kommer att avvisas, även om auktoriseringskoden har registrerats.
4. Testa flödet: En lyckad PKCE-aktiverad inloggning ser identisk ut med en vanlig SSO-inloggning ur användarens perspektiv. För att bekräfta att det fungerar, kontrollera att URL:en för auktoriseringsbegäran innehåller parametrarna code_challenge och code_challenge_method. För att testa säkerhetsgarantin, försök att spela upp en infångad auktoriseringskod utan kodverifieraren. Identitetsleverantören bör avvisa tokenutbytet med ett felmeddelande.
PKCE är en av de mer praktiska säkerhetsuppgraderingarna som finns tillgängliga för OAuth SSO på Joomla eftersom den löser ett verkligt problem utan att skapa någon friktion för användarna. Inloggningsupplevelsen förblir exakt densamma, men auktoriseringskoden blir värdelös för alla som avlyssnar den. I takt med att PKCE blir den förväntade standarden för OAuth-distributioner, håller aktivering via miniOrange OAuth Client-tillägget din Joomla SSO-konfiguration i linje med nuvarande bästa praxis och blir lättare att försvara vid en säkerhetsgranskning.
Tack för ditt svar. Vi återkommer snart.
Något gick fel. Skicka din fråga igen
Innehållsförteckning
Behövs hjälp? Vi är här!
