Share login between webapp and chrome extension

[Ronak Bhandari]

Hello.

I have a chrome extension with its independent login. Now I am building a webapp and I want the login to be shared that is if user logs in from webapp, they get auto logged in the plugin and vice versa.

I have been able to achieve one way that is if the user logs in the plugin, the cookies are set in the browser for the webapp domain using the content scripts.

How to achieve/ access the logged in cookie of the web application from the browser to the extension so the user gets auto logged in the extension.

--

Regards,
Ronak Bhandari

[Ronak Bhandari]

Hey guys. Any help available?

Regards,
Ronak Bhandari

[ilyaigpetrov]

Hi, Ronak.

I don't know how to do this, but you may search in direction of an identity api: https://developer.chrome.com/docs/extensions/reference/api/identity.

It may work if you use Google auth in your flow.

The API is not compatible with FireFox.

[ilyaigpetrov]

Found out FireFox supports some level of the api: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity.

[Lu Xu]

Hi Ronak,

if you add your authentication server url to the manifest host permission, then cookies will be shared on both web app and extension service worker.

So if your authentication only need session cookie, after your authentication is done on web app (server sets the cookies), then you can make APIs in extension service worker to fetch the resources

but if you don't add the server to host permission or you also need access token, this approach won't work 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5cb908be-f068-4b14-84fe-20e300ae6b44n%40chromium.org.

[Ronak Bhandari]

Thank you guys for the possible solutions.

@ilyaigpetrov Unfortunately, we are not using Google auth workflow at the moment. Though we could consider the Chrome identity APIs later when we have Google auth implemented.

@thusimon Our current implementation is access token based and there is no session cookie being set by the server.

I came across couple of articles talking about SSO approach. Eventually, isn't there any frontend only solution for the same?

--

Regards,
Ronak Bhandari

[Viet Ta]

Something from the top of my mind, maybe you can use the sync storage: https://developer.chrome.com/docs/extensions/reference/api/storage#property-sync

[Lu Xu]

Another idea, if you also own the WebApp, you can send the access token to extension, either using externally_connectable, or just use custom Events if your security requirement is not high (these custom events can be received by other extensions' content script)

[Ronak Bhandari]

@'Viet Ta', chrome sync won't be suitable for my use case as our users might not be logged in to the chrome or might be using multiple chrome accounts.

@Lu Xu  Externally connectable will work pretty well when the extension is at least installed and enabled if not open. What if the user has logged in the webapp and shut the webapp. Then installed the chrome extension and starts using it. In this scenario, how will the cookie info of the webapp be shared with the extension?

--

Regards,
Ronak Bhandari

[Roberto Oneto]

if you add your authentication server url to the manifest host permission, then cookies will be shared on both web app and extension service worker.

I was wondering if it was possible to prevent this behavior instead.

Let's say my extension logs in to a server with credentials saved in the extension's storage (or types when the extension needs them)..

These credentials are transmitted through a fetch command with the post method, simulating the compilation of the login form and its consequent submission. Now I would like the session cookies saved after login not to be shared with the cookies that the user saves during normal browsing (not through the use of the extension).

Is it possible to isolate extension cookies from normal browsing cookies

so the user would be logged in only via the extension and would be logged out if they tried to reach the login page via normal navigation?

[Jackie Han]

> Is it possible to isolate extension cookies from normal browsing cookies? These credentials are transmitted through a fetch command with the post method...

Yes, `fetch()` API supports it.

fetch("https://example.com", {
  credentials: "omit", // no cookie send
});

More details see here.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/46e826e1-edea-4961-8cf4-22c948bc5b63n%40chromium.org.

[Roberto Oneto]

Hi Jackie and thank you for your reply.

Correct me if I'm wrong: with the "omit" clause no cookies are sent to the server and when I get a response no cookies are set on the client?

If these cookies are not saved on the client, how can I access (via the extension) another resource\page that is beyond the login page?

[Jackie Han]

Copied from the official doc: "omit: Tells browsers to exclude credentials from the request, and ignore any credentials sent back in the response (e.g., any Set-Cookie header)."

The `credentials` parameter gives you three possible values: same-origin, include, omit. How to use it depends on you.

[Lu Xu]

@Ronak Bhandari , I guess even if you close the web app then install the extension, the cookies are still shared in the extension. but you can double check. After you added the url to host permission, when service-worker makes requests to that host, it is like making the same request on the browser tab, but please note there are some forbidden headers, like "Origin", will be different.

To get access token if your web app is closed. You can 1). if your auth-flow supports it, you can re-obtain access token in service-worker since you already have the cookies; 2). try offscreen document, open your webapp in offscreen document and send the token to extension. Or if your user experience requirement is not high, extension can quickly open webapp in a tab and close it...

@Roberto Oneto, @Jackie Han , if you use omit, then I guess the extension can login once, but can not keep login because all the cookies will be missing. Seems it requires that if the request is from extension, always include credentials (cookie will be set), but if the request is from tab, do not add these previously set cookies, browser need to treat cookies differently based on the request initiator. It seems impossible only by extension. But if you own the server, there should be solutions, from high level, your server should be able to distinguish the requests from web app and extension, then it can handle them differently. e.g, if server detect the request is from tab, just invalidate the session and clear cookie in response

[Roberto Oneto]

@Lu Xu & @Jackie Han

I don't think "credentials: omit" is the right way.

The browser should separate (at developer or user request) the cookies that need to be saved into separate "worlds".

Obviously it is useless (or worse yet harmful) to delete the cookies that store the session through the extension and repeat the login phase every time I need to access a resource\page beyond authentication.

If by chance the user had logged in to the server even through normal browser navigation he would find himself "inexplicably" logged out.

[Jackie Han]

(fix a typo)

@Roberto,

I am not sure I understand your thoughts.

 > if you add your authentication server url to the manifest host permission, then cookies will be shared on both web app and extension.
Yes, this is true at present.

> Roberto wants to separate extension login and website login
First, let's assume that you own this website and your website uses cookies as login credentials for web users.
Then, you can use other ways as login credentials for extension users. Note that cookies are just a special HTTP header. For example, you can use a custom HTTP header for extension login credentials. And "credentials: omit" is used for disabling cookie credentials. Thus, the extension credentials and the website credentials are separated.

This is a workaround that I have come up with to solve your problem. Of course, this requires your server to support two authentication methods.

On Sun, Apr 28, 2024 at 10:14 AM Jackie Han <han.g...@gmail.com> wrote:

@Roberto, 

I am not sure I understand your thoughts.

 > if you add your authentication server url to the manifest host permission, then cookies will be shared on both web app and extension.

Yes, this is true at present.

> Roberto wants to separate extension login and website login

First, let's assume that you own this website and your website uses cookies as login credentials for web users.

Then, you can use other ways as login credentials for web users. Note that cookies are just a special HTTP header. For example, you can use a custom HTTP header for extension login credentials. And "credentials: omit" is used for disabling cookie credentials. Thus, the extension credentials and the website credentials are separated.

This is a workaround that I have come up with to solve your problem. Of course, this requires your server to support two authentication methods.

[Roberto Oneto]

> if you add your authentication server url to the manifest host permission, then cookies will be shared on both web app and extension.

I didn't write that. I've always thought that include server urls permits to make CORS request throught extension when the server normally not deal with other origin than its (or a set of origins decided by web admin).
Cookie instead are set on server request via a response header both I'm dealing with an extension or not.
Furthermore many server can be reached even if their ulrs have not been included in "host_permissions" section.

Apart from this spartan clarification, I will now try to better explain the use case I had raised.

Let's say I developed an extension that logs in to Pinterest and fetches the first image from the Pinterest profile I logged in with.

I don't own Pinterest, so I cannot build 2 different authentication methods.:-)

For simplicity, let's assume that the user and password have already been stored within the extension.
This image will then be shown in a window, tab or popup (the destination does not matter).

Before starting to write some code I spied a little behind the scenes to understand how Pinterestlogin credentials are transmitted and I discovered that this information is transmitted with a normal POST request to the server.

I take note of all the fields necessary for this kind of request and I mimic it down to the smallest details inside my extension.
I then went to take a look at the response that the Pinterest server returned to me in case the login phase failed and in case it was successful.
If I was successful, all I have to do is analyze the response that the server returned to me (the HTML document) and extract the image using the most common JS methods to select DOM elements.
I display the image in the popup and that's it.
So far I hope I have been clear.

Now, without my extension explicitly logging out after capturing the image, I go to write the Pinterest URL in the address bar (of the SAME browser where the extension was installed) and I notice that I am not being asked login credentials as I am already logged in!
I am logged in because the cookies that Pinterest asked the browser to save on the browser (via extension) are the same ones that will then be read by normal navigation (i.e. through the address bar) of the same browser.
So far I hope I have been clear.

Now I get to the crux of the matter which is my clearly offtopic question from the initial thread (by the way, I apologize to @Ronak Bhandari).
My question is very simple: is it possible to somehow isolate the cookies saved by the extension so that they are not then read by browsing outside the extension?
If I now opened another browser (i.e. Firefox) and tried to reach the Pinterestr page I would NOT find myself logged in as on the same browser where I operated with the aforementioned extension.

So is it possible or will it ever be possible and\or desirable to have a world of cookies extension separate from the world of cookies of other types of navigation?

It could also be seen as having a browser instance (extension) inside a browser instance (the client) and the two instances are well isolated (at least as far as cookies are concerned and only if\when the user or developer request for this behaviour).

A bit like injected content scripts can be isolated from the page's native JS code (default) or access what is called the "main world"

[Jorge Dardon]

Yes, you can do this. I do this already by using firebase V9 on both the web application and the chrome extension. You can sync up authentication afterwards with Chrome.Storage afterwards. Works perfectly

[Rajat Paharia]

Jorge can you please explain how you're syncing up the authentication between the extension and the web app? I'm also going to need to figure this out at some point. Thanks! - rajat

[Jorge Dardon]

Rajat,

on the service worker side, you download the firebase-app and firebase-auth files and include them in your index file. In your service worker script, you set up the firebase config and use chrome.runtime.onMessageExternal.addListener function to listen to a message from your web app. In your web app, you can send the token or some message to signify that your user has logged in, and then sign in with firebase on the chrome extension side.

You can also sync up log outs this way.

You can use Chrome.Storage to pass the data to content script or other parts of the extension if needed.

[Rajat Paharia]

Thanks Jorge, that makes sense. I was curious more about the specifics of what data field are you passing back and forth and what Firebase auth method are you using on that data field to login. I'm guessing user.getIdToken or user.getIdTokenResult and signInWithCredential? How do you build the arguments for signInWithCredential? 

thanks! - rajat