[
https://issues.apache.org/jira/browse/SOLR-16896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lamine updated 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"
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.’
was:
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.
> 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
> 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" 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: [email protected]
For additional commands, e-mail: [email protected]
