Plasmo with auth0.com
I am trying to use https://auth0.com/ for authentication in my chrome extension.
Finding it hard to find resources that handles that with plasmo. All i saw on the offical plasmo doc was plasmo with supabase, and firebase auth.
I am wondering if i can setup my auth0 authentication the same way I will set it up in a reactJs application.
Auth0
Auth0: Secure access for everyone. But not just anyone.
Rapidly integrate authentication and authorization for web, mobile, and legacy applications so you can focus on your core business.
12 Replies
I would have to imagine it's possible. I'll probably be tackling this in the next month or so. My best guess is you would have to create a page and either use the lock.js widget or direct the user to the Auth0 domain which would then return you to the extension.
If its a react page you could prob just use the auth0 hook method
loginWithRedirect to pass the user to the page. Then in your tenant configure the redirectTo to be your a page in chrome extension. From there you can just use the token as normal.Chrome extension pages can be accessed VIA a URL. https://docs.plasmo.com/framework/tab-pages
But now that I think about it, I wonder if auth0 would allow a non-http protocol.
Plasmo Docs
Tab Pages – Plasmo
Learn how to use tab pages with Plasmo to create new tab views in your browser extension.
Any good news? I'm also using Plasmo + Auth0 for my chrome extension, and not able to easily make it work...
Were you ever able to figure this out?
Got this to work using hard coded extension keys, the options page, and logiinWithRedirect
@brent-silkline#1 once you get an access token, do you store it in storage so that it can be easily retrieved in all parts of your extension? (popup, content scripts etc)
How do you deal with the access token refresh or extension reloading ?(need to get another access token)
I planned to rely on the storage as a global auth state
So that in every part of the extension (content scripts, popup ..),
I check in the storage if we have an access token and maybe a userId, if we don't -> we show a button "login" to redirect to a tab page where we deal with the Auth0 redirect flow -> when the user login with Auth0, the callback redirect to this same tab page and then we store the access token in the storage
But I imagine the problem with this approach is that when the user reload Chrome / or the Extension is updated etc
=> we need to ask the user to login again to get an access token ?
@RL has reached level 1. GG!
Found this thread -> https://community.auth0.com/t/auth0-in-chrome-extension-content-background-script-mv3/74603/4
Basically:
- never store the access token, have the whole auth logic in a Background Service Worker, make any code (popup, content scripts) message the background worker to make authenticated API calls, check if the user is logged in or not etc ..
- use Authorization Code Flow with PKCE (because we can't use the normal Auth0 Authorization Flow in a service worker, it needs access to the DOM)
Auth0 Community
Auth0 in Chrome Extension Content/Background script MV3
Hi I got it working with manifest v3 & pure js: I have a loginpopuphtml that references a login.js script. Here is the content of the login.js script. Heavily influnced by: Robert Tolton | Implementing Auth0 Authentication into a Chrome… and Call Your API Using the Authorization Code Flow with PKCE. var btnLogin = document.getElementById("btnL...
I'll try to implement it
@louis that would make a good example for Plasmo with Auth0, juste une idée 🙂
Might be simpler to just use the normal Auth0 flow in a dedicated webpage and store the access token in secure storage, but it is secure enough ?
Maybe - with secureStorage, you basically delegate the master password storage to the user and hopefully they use a proper password manager
It really depends on how you want your extension structured (and the UX)
Hum yes doesn't seem optimal
The absolute best would be to have the service worker deal with the access token for every request, asking Auth0 to provide one of the fly and never store it
Not sure how to achieve this, it seems like this is what they are doing in the provided Auth0 forum link, will try to implement it
The absolute best would be to have the service worker deal with the access token for every request, asking Auth0 to provide one of the fly and never store itYeah - this is the PKCE flow, which is recommended for native devices including desktop and extensions. You'd mint a new token each time the user call your API, given that they had an older access token for the base auth
Interesting
Thinking about it, an option would be to save the access token temporarily in a global variable in the BGSW?
So that it can be re-used (and avoid increased load on the Auth0 servers and slower response times if we ask for a new access token on each API request) the time the service worker is still active, otherwise -> fetch another access token from Auth0