[
https://issues.apache.org/jira/browse/SOLR-16896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-16896:
----------------------------------
Assignee: Jan Høydahl
> 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
> Reporter: Lamine
> Assignee: Jan Høydahl
> Priority: Minor
>
>
> 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|https://issues.apache.org/jira/browse/SOLR-16897]"; 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.’
>
>
>
--
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
