Browser extensions, google, phoenix oauth openid ueberauth

[jschoch]

Oh the joy of learning all about authentication!

I’m writing a chrome extension and I have a backend service that I need to have it talk to. I also have a web frontend with ueberauth-google + guardian and I’d like to share as much as possible. Though lots of failure I’ve learned that I can get chrome to give me an id_token, and I can get an auth_token, but I can’t get an auth_token with the same oauth client_id I’m using for phoenix+ueberauth-google.

It seems that since I’m using google for all auth currently this should be more straight forward. Am I missing something?

Assuming I"m not missing something, below is what I plan on doing.

1. user creates an account in my system using google oauth to provide a google “sub” validated by the id_token produced by ueberauth-google. once registered i then use guardian sign_in to create a cookie for future signin.
2. user installs chrome extension. chrome.runtime.onInstalled() is triggered which I then use to start chrome.identity.launchWebAuthFlow(…) which ultimately provides the extension an id_token.
3. the extension sends the id_token to phoenix which uses either the tokeninfo endpoint or JOSE.JWT.verify (leaning on tokeninfo for this first extension authentication). If verified the token is stored and associated with the user.
4. Assuming it is verified phoenix sends back the user_id for my application and start tracking the expiration of the id_token.
5. Assuming the token is still valid the extension can use the whole id_token as a key for signing a JWT where the id_token is the JWT secret string since it has already been exchanged with phoenix and associated with the user.
6. when the id_token expires get a new one and go back to step 3.

I’m assuming that I can’t reuse any of the authentication logic for a web-user that I can for an extension user, and that all extension requests should be processed in a completely separate stateless token pipeline. Is this correct?

Bonus Question:

How hopeless is supporting firefox extensions in the above scenario

[jschoch]

I thought I’d list this as a reference. it is not what I want to do, but it is related and I didn’t’ see it in the suggested topics list and only found it today.

Chrome extension with Google OAuth and Phoenix backend

Hello, I realize this is kind of a mixed-up topics question, but I think I will ask anyway, hopefully I get useful feedbacks This is an architecture question. I have an API service built using Phoenix. Among others, it will handle user registration, but to ease the adoption I’m intending to only open registration using social media accounts (right now only Google, possibly with Facebook in the future); all the OAuth basic stuff and I will save the authenticated user’s name and email to…

Still wondering…

[bobbypriambodo]

Hi, I’m the thread author that you listed as reference. As said on the thread, I solved it using the approach of offloading the auth using Ueberauth on the Phoenix backend. With this approach, it should be trivial to add Firefox support, since you don’t depend on the chrome.* API (I have no idea how straightforward it is to translate it to FF extension lingo, but without it I think the flow is agnostic enough), but only the opening-tabs and listen-to-url-changes features, which I think is common enough for extension APIs to have. Doing the auth in client by utilizing chrome.identity seems to much work and error prone for me at that time.

Hope it helps.