[master issue] option to use custom IdP on browser extension

[tomholub]

Today, the browser extension uses Google authentication / IdP for two purposes:

1. authorizing use of Google APIs (gmail permissions) and then authenticating on those APIs
2. authenticating oneself when communicating with backend / Enterprise Server

For the second usecase, it would be safer to use some other IdP if the customer has that option. That way, Google cannot forge authentication tokens and steal the keys from EKM. Today, to prevent the potential key theft from EKM by Google, customers have to either run EKM behind a firewall on internal network, or not run it at all.

Allowing a custom IdP for authenticating especially with EKM would allow us to run EKM for our customers, meaning easier deployment.

This will mean, on such deployments when custom IdP is configured, the user will have to authenticate twice during setup. Once with Google for Gmail API and permissions, and once again with the custom IdP. (there will be two authentication popups in sequence)

The steps would be:

• add OAuth class #5316
• add custom authentication config to local store #5317
• add skeleton of ConfiguredIdpOAuth class #5318
• rename GoogleAuth to GoogleOAuth #5319
• ConfiguredIdpOAuth should produce an oauth window + save JWT to storage #5444
• if special JWT is stored in local store, it should be used for Enterprise Server authentication instead of Google JWT #5799
• we should differentiate GoogleAuthErr and EnterpriseServerAuthErr. When custom IdP is used and it is EnterpriseServerAuthErr, we should be showing ConfiguredIdpOauth popup instead of GoogleOAuth popup #5801
• test and possibly fix situations when custom domain authentication was added after extension was already set up. Similarly, test situations when it was removed.

[ioanmo226]

For the last task, I think I need @sosnovsky and @martgil help.
I've tested this situation and it works well in my side though.

[ioanmo226]

Could you try to build extension from master branch and test this situation?

[sosnovsky]

Yes, I'll test such situation. Probably it's possible to implement such ui test?

[ioanmo226]

UI test (for such case) was already added in previous PR I think.
We set invalid customIdpIdToken and removed custom_idp_token_refresh(which is same case when custom domain authentication was added after extension was already set up)

https://github.com/FlowCrypt/flowcrypt-browser/pull/5814/files#diff-a9d95eb676c3bf52fd1efc2f9a7e897c9278def726c3acc410ff6b67579487ccR2579

await BrowserRecipe.setInMemoryStore(settingsPage, acct, 'customIdpIdToken', MockJwt.new(acct, 100));
await settingsPage.setLocalStorage(cryptup_${emailKeyIndex(acct, 'custom_idp_token_refresh')}, null);

[sosnovsky]

Ah, I see, yes, seems to be similar to the described situation, then no need for separate test.

[ioanmo226]

How's this test going?

[sosnovsky]

Haven't fully tested it yet, but seems to work well after custom IdP was added after previous non-custom configuration.
However, sometimes I get such popup on my personal @flowcrypt.com account, may be related to my test local configuration changes, as it's quite random and usually disappears after browser restart or extension reinstall:
(Re-connect account button isn't working, throws error in console, but I didn't save it)

[ioanmo226]

Let me check

[sosnovsky]

Let me check

Probably it's related to my local test configuration, not sure if it'll occur for real users, so let's not try to fix it for now.