Migrate to oidc-client-ts (successor project of oidc-client-js)

[angelo-v]

Search terms you've used

• oidc-client-js
• oidc-client-ts

Impacted environment

In which environment would the proposed feature apply ?

• The browser
• Node.js
• Other (please specify): ...
• I'm not sure.

Feature suggestion

Since oidc-client-js is no longer maintained and further development is instead going on in oidc-client-ts I would like to see this library use that maintained dependency.

Expected functionality/enhancement

This is part of my endeavour to support Solid Login within browser extensions and specififally migrating my extension to chrome manifest v3.

I am willing to adjust oidc-client-ts to support service workers, if solid-client-authn-js will then actually make use of it.

Actual functionality/enhancement

Currently solid-client-authn-js depends on a fork of oidc-client-js

[angelo-v]

There seem to be only a few changes to do this as #2206 shows. We still need to take a look at the details, but let me know what you think about using oidc-client-ts in general, before I move on with it.

[NSeydoux]

Hi @angelo-v, and thanks for the suggestion! We are looking at some internal refactoring to the auth library pretty soon though, so I'm not sure doing this now would be the best timing. I'll update this issue soon (probably this week or next) with the planned changes to see if the issue still makes sense, is that ok with you?

[angelo-v]

Sounds good to me.

Please note that I managed to use solid-client-authn-js within a chrome extension by doing some manual setup of a ClientAuthentication with a custom redirector. I am using some internal types / imports from this lib. Everything is put together here. I wonder if this might break with your refactorings.

In general it would by very helpful if solid-client-authn-js would became more extensible and modular (I had to copy paste some code, rely on deep imports and instantiate a lot of classes although I only wanted to exchange the redirector and the logout handler). Will this be covered by the refactoring? I could create another issue for this. Perhaps we can even include support for browser extensions directly to solid-client-authn-js with what I have learned in my extension? What do you think?

[angelo-v]

Hi @NSeydoux how is it going? Any updates on the planned changes you mentioned? Did you have a chance to look into my customizations mentioned in the last comment?

[ThisIsMissEm]

Hi @angelo-v, sorry for the delayed response, we're still working on the plan and the changes, but it's a major refactor of this library, so takes quite an amount of time to plan. I'll try to get us to give an update when have more details to share.

[Hewlbern]

Hi @angelo-v , I'm looking at your code right now, and trying to use it with the newer library for my own chrome extension.

@ThisIsMissEm Would love some guidance on a good flow just to do login in a chrome extension.

[angelo-v]

@Hewlbern hope my code helps. Sad that there is no progress from inrupt in that regard. Solid Browser extensions would be a game changer

[ThisIsMissEm]

Hi @angelo-v , I'm looking at your code right now, and trying to use it with the newer library for my own chrome extension.

@ThisIsMissEm Would love some guidance on a good flow just to do login in a chrome extension.

@angelo-v @Hewlbern I can't help, I no longer work at Inrupt.

[NSeydoux]

Would love some guidance on a good flow just to do login in a chrome extension.

@Hewlbern I am not familiar with Chrome extensions, but in the past I was able to implement a Firefox extension using the browser.identity API, which is also available on Google Chrome. I have no idea how this will be impacted by the Manifest V3 changes though.

The general idea is that the browser API will give you the callback URL when you call the launchWebAuthFlow function. You can use the regular session.handleIncomingRedirect({ url: callbackUrl }); to authenticate the session of your browser extension.

I'm not sure why this conversation is applicable to the topic of this issue. If there is a specific problem with oidc-client-js in the browser extension, can you elaborate on it? And otherwise, if there is any other issue specific to browser extension development, can you open a dedicated issue?

I don't have a roadmap for the changes initially discussed in this issue, so I can't commit to them being done at a specific date, but this is still something we are aware of and will eventually get to.

[angelo-v]

Hi, I did not follow up on recent developments, but what blocked me and lead to this issue is that oidc-client-js is deprecated and does not support service workers, which are needed for manifest v3.

It should be all described / linked in the original issue comment above, if any of the assumptions do not hold true anymore let me know