Authenticating a Chrome extension with Elixir back-end

I am trying to create a Chrome extension which should require authentication to be able to do certain things. I’ve never created an extension before so I am learning and trying to implement. What the extension will do is embed some buttons/links on pages of some domain, which will send requests to my Elixir back-end upon clicking.

The extension part is not really a problem, where I am stuck is authenticating users for the extension. How do I authenticate a user? The only example I have at hand is TunnelBear’s extension. After you install the extension when you click the extension pop-up, if you’re not logged in you get redirected to TunnelBear’s website for creating an account or logging in, on a new tab. Screenshot below shows the requests made before redirecting you to TunnelBear login/sign up page.

After you log in there’s a bearer token set, I think that’s being sent from the website to the extension by message passing but I don’t know about the details and then the extension keeps it in local storage I think.

So basically my question is how can I go about authenticating users for my Chrome extension with an Elixir back-end? Do I use Uberauth and Guardian and once the user logs in on the website I create a bearer token and pass it to the extension?

Extensions have their own “background script”, which is essentially a process running in the browser (not on dedicated tabs). You can think of this as your middle man back end. This is where you make requests to your backend from, and where you would store the auth token. You then basically pass messages from your browser extension script running on an individual tab to the background script to validate that a token is there before proceeding. There is some good info about working with the background script here: https://levelup.gitconnected.com/how-to-use-background-script-to-fetch-data-in-chrome-extension-ef9d7f69625d

I unfortunately don’t have access to the extension I worked on, and it was a while ago, so I can’t be a ton more help :stuck_out_tongue:

1 Like

So, do I not store the auth token in a local storage? The user would then have to log in again whenever they close the browser, right?

Thank you for the answer! :slight_smile:

You can use cookies in the background page as well, which can be used to get a token or as the actual auth mechanism. I worked on a fairly complex extension and we still relied on cookie, but traded it for a token ASAP because it felt more future proof.

I’ve also implemented auth by having the web app send the token using chrome extension messaging API, then storing it in localstorage.

1 Like

There is a localstorage instance available specifically within the background script, and this is where you would store the token. That article I linked above outlines this in Part 4.

This is also what I was thinking. Basically redirect the user to the website and once they log in, send a token to the extension as well by message passing. Then once the user clicks on the extension again we can make a request to see whether the user is authorized or not.

How do you do that with cookies? I mean can you access the cookies of a browser? Like once the user logs into the website use the same cookie from the storage?

Oh, since you said that I was thinking you still keep it as a variable so that’s why I asked. I’ve actually used the local storage to try things out so I’ll be using that. However is there any way of seeing whatever is in the local storage of an extension? By inspecting the script from extensions page I don’t see anything in the local storage, I can see the requests made by the script though.

I’ll definitely read the article by the way!

background page scripts include cookies when they make requests (HTTP only cookies, not accessible via JS). You don’t have to do anything special to my knowledge, although maybe there needs to be a domain permission defined in the manifest?

Caveat: this was all v2 manifest. The v3 manifest is changing a lot and I’m not sure how this holds up. However, v3 has been in the works for multiple years and still isn’t firmly announced.

1 Like

So, if I can still use cookies, can I basically do the login/sign up (and all the other things) through the extension as well without a JSON API? What I mean is basically make an HTTP request and show the returned HTML page within the extension pop-up. I don’t know if that makes sense.

What I was thinking is to use a JSON API with a bearer token for the extension because that’s what the extensions I’ve inspected so far were doing.

Possibly, you could with an iframe. I’d recommend a normal tab based flow that messages the token to the extension

1 Like

Do I need any permission for the iframe? Because when I simply place an iframe, I just see a gray image instead of iframe. And what you suggest is by using a JSON API with a bearer token passed to the extension by the website, right? I don’t really know the terminology, sorry. :smiley:

There are quite a few reasons I said possibly for the IFrame. Typically, you don’t allow the login page to be embedded in an IFrame to prevent hijacking. Most likely the IFrame is failing to load because of a policy that prevents it from being embedded. You can not get around that, even with an extension. The nuances of IFrames is why I would say to not use one and to do a typical web-based login flow.

I am not really advocating for anything regarding what type of API / token you use. I typically do use a JSON API with the authentication token in the Authorization header, but ultimately you just need to build a system that takes in the token and allows it to make requests.

1 Like

Alright, thank you so much for all the answers. I’ll just start implementing that part and probably improvise on the way. :smiley: Sorry for the delay, I just didn’t have much time nowadays.

Cheers!