OpenID Connect Integration

[colin-campbell]

Since this plugin is generally available in the Chrome Web Store, it would be a real plus for businesses to have it useable over the Internet with proper authentication, authorisation and sign-in.

OpenID Connect, for instance is doable in a browser extension, but with some tricky things in the manifest around site access, etc. Maybe Microsofts MASL.js could help us here.

If there is enough interest here, I will try to make an implementation of this - it would be great for corporate users to be able have this installed through MDM and ready to go out-of-the-box with settings, as it were.

What do you think?

[n4ze3m]

This is great! I also planned a similar feature after releasing OpenAI API-compatible support. The n4ze3m/page-share-app will be updated to include an admin panel where users can add their Ollama, Llama.cpp, or any OpenAI-compatible endpoint. It will then act as a proxy with role-based controls, etc., for the Page Assist extension

[therealtimex]

This is great! I also planned a similar feature after releasing OpenAI API-compatible support. The n4ze3m/page-share-app will be updated to include an admin panel where users can add their Ollama, Llama.cpp, or any OpenAI-compatible endpoint. It will then act as a proxy with role-based controls, etc., for the Page Assist extension

Love this idea.

[colin-campbell]

I have a basic working version that has successfully authenticated against Keycloak OpenId Connect using Authorization Code Flow with PKCE from background.ts.

I had to "roll my own" using the WebCrypto API, https://www.w3.org/TR/WebCryptoAPI because MSAL, and other available libs are relying on node builtins which are playing havoc with the Vite config and are proving difficult to shim - vite-plugin-node-polyfills for example doesn't work for this use-case unless I am missing something.

I don't think it's a biggie, because of the simple flow ACF-PKCE being the only one really suitable for this type of application, and the available libs are over-engineered to the max to support all standard flows.

So just some scaffold to do around token expiry, refresh and collecting the config parameters, and I should have an experimental PR by the end of the week.

One question: I was thinking of keeping all that stuff hidden from the user unless the initial call to /api/tags returns 401 Unauthorized, then we should display a "sign in" button. What do you think @n4ze3m @therealtimex?

Of course centralising all this in some sort of proxy makes some sense, but having standalone operation with only the extension is a worthy effort too.

[therealtimex]

Why not adding a menu here:

[colin-campbell]

I will of course add a menu for settings/endpoints there. But the auth itself should happen in the service worker using launchWebAuthFlow() which will take care of the authentication lifecycle without using the UI at all.

[n4ze3m]

Wow, this is amazing! I'm pinning this issue as a v2.0.0 discussion.

[therealtimex]

I will of course add a menu for settings/endpoints there. But the auth itself should happen in the service worker using launchWebAuthFlow() which will take care of the authentication lifecycle without using the UI at all.

definitely