Overview

When a user logs in to a Joomla site through OAuth SSO, the identity provider sends back an authorization code through the browser. The application then exchanges that code for an access token. This works well in most cases, but there is a problem: if someone manages to intercept that authorization code before it reaches the application, they can use it to get an access token themselves.

PKCE (Proof Key for Code Exchange) prevents this. Before the login starts, the application generates a random secret, sends a hashed version of it to the identity provider, and then proves it holds the original when exchanging the code for a token. An intercepted authorization code is useless without that proof, because only the original application has it.

The miniOrange Joomla OAuth Client extension supports PKCE out of the box. Enabling it adds this security layer to your existing SSO setup without changing anything about how users log in.

Prerequisites

To enable PKCE-protected OAuth SSO on a Joomla website, you will need the following:

miniOrange OAuth Client Extension for Joomla

Download Extension

Challenge

Most Joomla sites running OAuth SSO use the default authorization code flow without PKCE. This is fine for many scenarios, but it creates some real risks worth understanding.

Authorization codes pass through the browser as URL parameters, which means they can end up in browser history, server logs, and referrer headers. There is a window, even if brief, where they are exposed. For applications that cannot store a client secret safely, like single-page apps or browser-based SSO flows, the authorization code becomes the only thing standing between a user's account and an attacker who got their hands on it.

OAuth 2.1, which reflects current security best practices, makes PKCE mandatory for all authorization code flows. Organisations working toward compliance with standards like SOC 2 or ISO 27001 are increasingly expected to have this in place.

Without PKCE, there is also no cryptographic proof that the client completing the token exchange is the same one that started the login. That gap makes clean security audits harder to produce.

Implementation

Setting up PKCE through the miniOrange OAuth Client extension is straightforward. Here is how the configuration comes together.

1. Enabling PKCE in the Extension: In the OAuth provider settings inside the miniOrange extension, there is a dedicated option to enable PKCE. Once turned on, the extension takes care of everything automatically: it generates a random code verifier at the start of each login, creates a hashed challenge from it, and sends that challenge to the identity provider as part of the authorization request. When the token exchange happens, the original verifier is sent alongside the authorization code so the identity provider can confirm they match.

2. Choosing the Code Challenge Method: The extension supports two methods: S256 and plain. S256 hashes the code verifier with SHA-256 before sending the challenge, which means the original secret is never transmitted. The plain method sends the verifier directly as the challenge, which offers no real protection. For any live Joomla site, S256 is the right choice, and most modern identity providers support it.

3. Updating the Identity Provider Configuration: On the identity provider side, the application registration should be updated to require PKCE. This usually means marking the application as a public client or enabling PKCE enforcement in the app settings. The exact steps vary by provider. Making PKCE required at the provider level matters because it means any token exchange attempted without a valid code verifier will be rejected, even if the authorization code was captured.

4. Testing the Flow: A successful PKCE-enabled login looks identical to a regular SSO login from the user's perspective. To confirm it is working, check that the authorization request URL includes the code_challenge and code_challenge_method parameters. To test the security guarantee, try replaying a captured authorization code without the code verifier; the identity provider should reject the token exchange with an error.

Conclusion

PKCE is one of the more practical security upgrades available for OAuth SSO on Joomla because it solves a real problem without adding any friction for users. The login experience stays exactly the same, but the authorization code becomes worthless to anyone who intercepts it. As PKCE becomes the expected standard for OAuth deployments, enabling it through the miniOrange OAuth Client extension keeps your Joomla SSO setup in line with current best practices and easier to defend in a security review.

Additional Resources

1. Access Security via Compartmentalization - OAuth Protocol in Joomla!
2. SAML vs OAuth in Joomla: Which should you choose?
3. Check out our documentation