laminelam opened a new pull request, #1791: URL: https://github.com/apache/solr/pull/1791
https://issues.apache.org/jira/browse/SOLR-16896 # 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" [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. # Tests Test cases added to the back-end PR. Front-end app does not support unit testing. Extensive tests were done on the browser. Ref guide to be updated. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
