#5444 ConfiguredIDPOAuth shows authentication popup and save JWT to storage

[ioanmo226]

This PR implemented feature to let ConfiguredIDPOAuth shows authentication popup and save JWT to storage

close #5444// if this PR closes an issue

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
Once a secret has been leaked into a git repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

[tomholub]

Some comments for code clarity, just a quick review

[tomholub]

Other than the redirect page in progress, my comments were addressed 👍

[sosnovsky]

Looks good for me 👍 Just need to fix redirect part mentioned by Tom.
Probably we can use launchWebAuthFlow method, which enables auth flows for non-Google IdP. There is also getRedirectURL method for generating correct redirect URL.

[ioanmo226]

I previously decided to use our own oauth solution instead of launchwebAuthFlow because of below reason.
Also we need to add identity permission in manifest.

#4660 (comment)

Looks good for me 👍 Just need to fix redirect part mentioned by Tom. Probably we can use launchWebAuthFlow method, which enables auth flows for non-Google IdP. There is also getRedirectURL method for generating correct redirect URL.

[ioanmo226]

The biggest problem with launchWebAuthflow is we have limited control for UI testing.

[sosnovsky]

Also we need to add identity permission in manifest.

Maybe it can be added without any additional confirmation popup, like scripting permission - it was added with manifest v3 migration and didn't require user confirmation.

The biggest problem with launchWebAuthflow is we have limited control for UI testing.

Probably it'll work the same as our current mock implementation - it'll open mock authorization endpoint and will wait until it receives auth token. Also a couple years passed since your initial comment about poor documentation, there should be more guides about it's implementation. I think it's worth to check these methods for our auth process, and if it's still broken - then try to use https://EXTENSION_ID.chromiumapp.org/oauth as redirect url (such urls are generated by getRedirectURL method)

[ioanmo226]

@tomholub and @sosnovsky,

I suggest updating our OAuth mechanism. Currently, we inject oauth2_inject.js in robots.txt to obtain the authorization code. Instead, we could set the redirect URI to https://{extensionId}.chromiumapp.org/, listen for chrome.tabs.onUpdated, and check if the tab ID matches the newly created auth window's tab ID and if the tab URL matches the redirect URI.
Then, we can retrieve the authorization code directly.
This approach mirrors what the launchWebAuthFlow function does.

Let me know your thoughts!

PS: We cannot rely on a content script solution for handling OAuth redirects. When OAuth redirects to our Chrome extension page (or to https://{extensionId}.chromiumapp.org), Chrome prevents the content from loading due to security concerns. As a result, the content script does not load, making it unusable for capturing the authorization code in this scenario.

[ioanmo226]

I agree.
Let me try with your suggested solution and then try with my above solution if it doesn't work.

Also we need to add identity permission in manifest.

Maybe it can be added without any additional confirmation popup, like scripting permission - it was added with manifest v3 migration and didn't require user confirmation.

The biggest problem with launchWebAuthflow is we have limited control for UI testing.

Probably it'll work the same as our current mock implementation - it'll open mock authorization endpoint and will wait until it receives auth token. Also a couple years passed since your initial comment about poor documentation, there should be more guides about it's implementation. I think it's worth to check these methods for our auth process, and if it's still broken - then try to use https://EXTENSION_ID.chromiumapp.org/oauth as redirect url (such urls are generated by getRedirectURL method)

[sosnovsky]

Let me try with your suggested solution and then try with my above solution if it doesn't work.
Sounds good, let's try it this way. Usually such native solutions work better in Chrome, and it'll simplify our code to something like this:

chrome.identity.launchWebAuthFlow({
  'url': authConf.oauth.authCodeUrl + '?client_id=' + clientId + '&response_type=token',
  'interactive': true
}, function(redirectUri) {
  // Extract token from redirectUri.
});

[tomholub]

Also we need to add identity permission in manifest.

Maybe it can be added without any additional confirmation popup, like scripting permission - it was added with manifest v3 migration and didn't require user confirmation.

The biggest problem with launchWebAuthflow is we have limited control for UI testing.

Probably it'll work the same as our current mock implementation - it'll open mock authorization endpoint and will wait until it receives auth token. Also a couple years passed since your initial comment about poor documentation, there should be more guides about it's implementation. I think it's worth to check these methods for our auth process, and if it's still broken - then try to use https://EXTENSION_ID.chromiumapp.org/oauth as redirect url (such urls are generated by getRedirectURL method)

The problem from what I remember was that the identity mechanism only allowed to authenticate with the account that is connected to your browser. So no multi user to my knowledge

I wouldn't start working on replacing that unless we run into a roadblock with our existing mechanisms. They work well imo

[ioanmo226]

Maybe we could only use launchWebAuthFlow for custom IDP authentication and keep using our customized OAuth solution for google IDP.
What's your thouht?

[ioanmo226]

Ohhh. just tested and this problem is now past story.
I can now login to any account. We can use launchWebAuthFlow solution for google IDP too I think

The problem from what I renege was that the identity mechanism only allowed to authenticate with the account that is connected to your browser

[tomholub]

@tomholub and @sosnovsky,

I suggest updating our OAuth mechanism. Currently, we inject oauth2_inject.js in robots.txt to obtain the authorization code. Instead, we could set the redirect URI to https://{extensionId}.chromiumapp.org/, listen for chrome.tabs.onUpdated, and check if the tab ID matches the newly created auth window's tab ID and if the tab URL matches the redirect URI.

Then, we can retrieve the authorization code directly.

This approach mirrors what the launchWebAuthFlow function does.

Let me know your thoughts!

PS: We cannot rely on a content script solution for handling OAuth redirects. When OAuth redirects to our Chrome extension page (or to https://{extensionId}.chromiumapp.org), Chrome prevents the content from loading due to security concerns. As a result, the content script does not load, making it unusable for capturing the authorization code in this scenario.

I would like to, but last I tried it didn't work. I think we are using web application type of oauth credentials in oauth settings on google, which doesn't allow setting this type of redirect url meant due extensions. While when trying to use the extension type, it had some other limitations making it unusable for our purposes (I think no pffline_mode or maybe something else). I wouldn't try to change anything unless we absolutely have to. If the current gmail mechanism works, I don't think we have to.

Of course, if I'm wrong and it's just a matter of adding this redirect url and a small code change, then sure. But from my experience, you'll run into a lot of dead ends.

[tomholub]

Ohhh. just tested and this problem is now past story.

I can now login to any account. We can use launchWebAuthFlow solution for google IDP too I think

The problem from what I renege was that the identity mechanism only allowed to authenticate with the account that is connected to your browser

If it seems easy to do and simplifies things then sure. Does it allow offline_mode? Also, does it work the same on firefox?

[tomholub]

But how about we leave existing google mechanism untouched in this pr if it works. Try out the new identity mechanism on 3rd party logins. That way no risk. We gain some experience with it in a low impact scenario.

Then we can consider changing google login as well in a separate PR in future version.

[sosnovsky]

Yeah, it should be safe to start using new identity flow for 3-rd party IdPs, and if no issues found - migrate Google IdP to it later.

[ioanmo226]

Sounds good!. Thank you

[ioanmo226]

Yeah, it works same on Firefox

If it seems easy to do and simplifies things then sure. Does it allow offline_mode? Also, does it work the same on firefox?

[tomholub]

code looks good on my end, didn't test it

[sosnovsky]

@ioanmo226 do you have active test instance of auth0? I tried to use credentials which you previously shared with me, but got error Authorization page could not be loaded.

[ioanmo226]

Yeah. I have active test instance. How did you test? With which client_id, client_secret did you test. And also did you test with local FES?

[ioanmo226]

Ohh. I just remember I rotated previous client secret because previous one was in git history.
Just sent new client secret to your email

[ioanmo226]

FYI, redirect_url in authentication.oauth is useless/not required in client configuration as redirect_url needs to be same for all oauth (custom IDP) configurations. (https://EXTENSION_ID.chromiumapp.org/oauth)

[sosnovsky]

I just implicitly set authentication configuration in fetchAndSaveClientConfiguration method, without local FES.
For redirect URL I used chrome.identity.getRedirectURL('oauth'), but it still gives me Authorization page could not be loaded. error.
My extension id is the same as I previously shared with you for redirect URL (pjohdcpiapjhagmakkjpgjmodmgfmkkd).

[tomholub]

FYI, redirect_url in authentication.oauth is useless/not required in client configuration as redirect_url needs to be same for all oauth (custom IDP) configurations. (https://EXTENSION_ID.chromiumapp.org/oauth)

Probably also true on android and ios, but it could be useful if we ever do authentication on the web. Once we figure this out, we'll update the docs.

[ioanmo226]

I haven't added bnjglocicdkmhmoohhfkfkbbkejdhdgc redirect_url before. Just added to my auth0 config. Please check again.

[sosnovsky]

All good now, works great, thanks!