[
https://issues.apache.org/jira/browse/SOLR-15434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17397971#comment-17397971
]
Jan Høydahl commented on SOLR-15434:
------------------------------------
It may be feasible to include an OIDC library for this. I looked at
[https://github.com/IdentityModel/oidc-client-js] which seems very popular, but
it is deprecated and not maintained, but
[https://github.com/pamapa/oidc-client-ts] is a recent fork that is rewritten
to TypeScript, although it only has an alpha0 release so far. Using a lib like
this should make the whole impl more secure. And hopefully we'd get token
refresh, logout support etc quite cheap as a result.
> Change JWT OAuth grant type to Authorization code instead of implicit for UI
> ----------------------------------------------------------------------------
>
> Key: SOLR-15434
> URL: https://issues.apache.org/jira/browse/SOLR-15434
> Project: Solr
> Issue Type: Improvement
> Components: security
> Reporter: Chelambarasan
> Assignee: Jan Høydahl
> Priority: Major
> Labels: JWT, authentication
>
> Currently admin UI looks for implicit grant type in solr 8.8.2 version. Since
> implicit grant/flow is deprecated in OAuth 2.1 draft we should consider
> Authorization Code Flow.
> Consider the IETF draft titled "[OAuth 2.0 for Browser-Based
> Apps|https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-06]";,
> which has this justification for the changed recommendation:
> {quote}There are several drawbacks to the implicit flow, generally involving
> vulnerabilities associated with the exposure of the access token in the URL.
> See Section 9.8 for an analysis of these attacks and the drawbacks of using
> the implicit flow in browsers. [...]
> In recent years, widespread adoption of Cross-Origin Resource Sharing (CORS),
> which enables exceptions to the same-origin policy, allows browser-based apps
> to use the OAuth 2.0 authorization code flow and make a POST request to
> exchange the authorization code for an access token at the token endpoint. In
> this flow, the access token is never exposed in the less secure
> front-channel. Furthermore, adding PKCE to the flow ensures that even if an
> authorization code is intercepted, it is unusable by an attacker.
> For this reason, and from other lessons learned, the current best practice
> for browser-based applications is to use the OAuth 2.0 authorization code
> flow with PKCE.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
