[SOLR-16896] add support of OAuth 2.0/OIDC 'code with PKCE' flow (front-end)

• Type: Improvement
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Fix Version/s: 9.4
• Assignee: Jan Høydahl
• Reporter: Lamine
• Created: 18/Jul/23 17:43
• Updated: 15/Oct/23 19:57
• Resolved: 13/Sep/23 22:31

Description

 

Solr’s JWT authentication plugin uses implicit flow to request Access & ID tokens via OIDC/OAuth 2.0.

Due to its inherent security weaknesses, such as potential exposure of access tokens in the browser's history or the risk of leakage at the redirect stage, the Implicit flow has fallen out of favor. Its usage has been deprecated in OAuth 2.1, and many OIDC/OAuth 2.0 providers no longer support it. A decade ago, Implicit flow was the only practical way to retrieve tokens in a single call through browser redirection when cross-origin requests were blocked to shield applications from cross-site scripting attacks.

However, the development of Single Page Applications (SPAs) and advancements in modern browsers' handling of CORS requests have made the Implicit flow obsolete. Current applications and Content Security Policies (CSPs) can be configured to permit CORS requests.

OAuth 2.0 offers various flows (protocols) suited to different use cases. The Authorization Code Flow, recommended for SPAs and native apps, is available in two variants:

• Authorization Code Flow with a secret: This involves server-side communication with the authorization server, necessitating secure secret storage. The retrieved tokens are then shared with the client.

• Authorization Code Flow with PKCE: Given that the source code of native apps and SPAs is accessible to client devices, storing the secret client-side is impractical. The PKCE solution facilitates an exchange of a verifier code between the client and the authorization server, granting access to the tokens. Hence the acronym: Proof Key for Code Exchange (PKCE).

Given that the Solr admin Webapp is an SPA, this contribution employs the PKCE method. However, we can incorporate support for the Authorization Code Flow with a secret, while still reusing the front-end code, to allow these two options to coexist in a configurable manner.

This implementation is expected to enhance security by mitigating the risk of token interception, ensuring tokens are delivered to the intended client, and providing a safer overall user authentication process.
  

More details are available in the below resources:

[OAuth 2.0 RFC (implicit flow)](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.2)

[PKCE RFC](https://datatracker.ietf.org/doc/html/rfc7636 )

[The State of the Implicit Flow in OAuth2](https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/)

[Why the implicit flow is no longer recommended](http://taithienbo.com/why-the-implicit-flow-is-no-longer-recommended-for-protecting-a-public-client/)

—

This PR represents the "front-end" part of the contribution. See the "back-end" part.

The PKCE code flow process retrieves tokens in two stages:

1. Acquire the authorization code via browser redirection.
2. Utilize the received code to invoke the /token endpoint and fetch the tokens.

For the sake of backward compatibility, the 'implicit flow' is maintained and established as the default mode.

 

One outstanding question is: how can we incorporate the /token URL into the list of allowed URLs in the CSP connect-src directive? For now, this is manually added in server/etc/jetty.xml.’

 

 

 

Issue Links

• is duplicated by: SOLR-15434 Change JWT OAuth grant type to Authorization code instead of implicit for UI
• links to: GitHub Pull Request #1791