[
https://issues.apache.org/jira/browse/SOLR-15434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419625#comment-17419625
]
Jan Høydahl edited comment on SOLR-15434 at 9/24/21, 7:39 AM:
--------------------------------------------------------------
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. A plus with these libs
is that they are maintained by solid organizations in the auth space ("openid"
and "ForgeRock"), who will likely keep them 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.
was (Author: janhoy):
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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
