[jira] [Commented] (SOLR-15434) Change JWT OAuth grant type to Authorization code instead of implicit for UI

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

    [ https://issues.apache.org/jira/browse/SOLR-15434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419625#comment-17419625 ] 

Jan Høydahl commented on SOLR-15434:
------------------------------------

I have found an alternative library: [https://github.com/ForgeRock/appAuthHelper] which is a wrapper around [https://github.com/openid/AppAuth-JS] taking care of all the code flow stuff in a ServiceWorker background thread inside an iframe (as does oidc-client). A plus with these libs is that it is maintained by "openid" and "ForgeRock", two organizations that will likely keep it up to date, as opposed to oidc-client-ts which is maintained by one person "pamapa" who I know nothing about, so the future of the lib is uncertain.

Reading the docs on both, oidc-client-ts looks like an easier integration, since it is very explicit and gives us various hooks we can use to initiate the flow, pull the token etc. It has a nice balance between control and automation. It supports storing token in local storage as we do today.

The appAuthHelper lib will inject itself to intercept all {{fetch()}} and {{XHR}} requests made by the app, to insert Authorization header. That is nice, but we need some more control, since the frontend will not know whether Solr is protected and if it is BasicAuth or JWT until the first request, so we'd need a way to control whether and when to start this injection (typically on the first 401 response with type Bearer). Then the lib will handle background token fetch and also silent refresh, NICE!

We may need to pass more config from backend in {{X-Solr-authinfo}} header since we'll need the token-endpoint-url and a few other.

Finally, it will take some effort to assemble the js files with all the dependencies from npm, since we don't use a bundler. Hopefully it is manageable.

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