Lamine created SOLR-16896:
-----------------------------
Summary: add support of OAuth 2.0/OIDC 'code with PKCE' flow
(front-end)
Key: SOLR-16896
URL: https://issues.apache.org/jira/browse/SOLR-16896
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Lamine
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"
[PR](https://github.pie.apple.com/IPR/apache-solr/pull/50).
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
