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

["Jan Høydahl (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-16896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Høydahl updated SOLR-16896:
-------------------------------
    Priority: Blocker  (was: Minor)

> 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: Blocker
>
>  
> 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org