Manifest v3 use case considerations

[Ryan Graham]

Somewhat related to the thread below:

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/xUOaqLomOV4/m/Ay_HngAxBAAJ

We are currently struggling to use the chrome.identity APIs to authenticate & authorize users:

• Users frequently want a different account than the one signed into Chrome (lots of weird UX edge cases here)
• Unable to log in with other providers (e.g. Microsoft. launchWebFlow does not work with some additional security providers like Duo)

And we observed that a lot of extensions are using the client-side gapi and msal libraries in their background pages. These libraries rely on the window object for data storage and UI, and so won't work in manifest v3.

How is the user supposed to get a non-interactive token in these cases? tabs & window.create are clearly not suitable for UX, we can't continually pop up to ask the user for a new token every hour and manually handling offline tokens is a security nightmare.

Have these use cases been considered? 

[thdoan]

I'm facing the same predicament, and as wOxxOm suggested on StackOverflow we should start submitting or voting for tickets on https://crbug.com/ to voice our concerns. I just submitted a preemptive ticket here:

https://bugs.chromium.org/p/chromium/issues/detail?id=1164452

[Kos]

> Users frequently want a different account than the one signed into Chrome (lots of weird UX edge cases here)

It's not an issue, identity allows you to select needed Google Account / add one if needed

> Unable to log in with other providers (e.g. Microsoft. launchWebFlow does not work with some additional security providers like Duo)

It's probably edge cases not related to OAuth itself.