Trusted Extensions for Authentication Providers (vscode-style Trust Mechanism)

[chroberino]

I’d like to explore the possibility of introducing a mechanism in Theia that enables trusted extensions to reuse authentication sessions or credentials/tokens/etc. -- similar to how VS Code handles authentication provider trust.

In VS Code, users can click “Manage Trusted Extensions” per account (e.g. GitHub) to see which extensions are reusing the authentication and configure or deny access on a per-extension basis (see screenshots). Often, trust is pre-established based on publisher identity, with the option for manual overrides.

My use case in Theia:

• I am implementing an authentication provider extension (e.g. for SSO to an internal service).
• I want only specific, trusted extensions to be able to re-use the authenticated session or provided credentials/tokens.
• Any other installed or third-party extensions should be prevented from accessing it.

This is essential for cyber security, as SSO sessions can grant broad access to backend systems.

Questions

1. Does Theia currently offer any form of trust enforcement at the extension level for authentication providers?
2. Are there any plans to support a feature similar to VS Code’s trusted-extension model for auth reuse?
3. What would be a secure and feasible approach to express and enforce trust between extensions?

For context, I don’t necessarily require a full UI like VS Code’s “Manage Trusted Extensions” dialog. The core need is a way to enforce trust in code -- for example, by ensuring only known, verified extensions can access authentication sessions.
However, if such trust enforcement cannot be reliably done in code alone, it may be necessary to delegate the decision to users or administrators, allowing them to explicitly define which extensions they trust to access sensitive authentication data.

Trust via Extension IDs?

One obvious mechanism would be to specify trusted extension IDs, but this raises concerns: In the current ecosystem, there’s no guarantee that an extension ID (e.g. publisher.extension) uniquely identifies a trusted party. Any extension could potentially use a well-known ID unless Theia verifies the publisher or origin.

If an extension is installed via .vsix rather than the Marketplace, the runtime cannot verify the claimed publisher identity. This makes it possible for a malicious extension to spoof a trusted ID.

In VS Code, some level of identity enforcement exists for Marketplace-installed extensions through publisher signatures, but even there, this breaks down with direct .vsix installs.

This suggests that trust enforcement would need to be backed by some form of signature, publisher verification, or isolated packaging, rather than just string comparisons.

This highlights the need for a stronger trust model -- ideally one that:

• Verifies the source of an extension,
• Uses cryptographic or container-based isolation,
• Or allows system administrators to define trusted extensions based on packaging provenance or deployment policies.

---

Side Note: I came across #15741, which touches on GitHub SSO behavior in Theia. It seems loosely related in terms of authentication/session management, which makes me wonder if there's already groundwork in Theia around account/session access policies.

[planger]

@chroberino Thanks for bringing this up! This certainly is a very relevant topic.

I think there is two sides to it:

1. The Theia framework side
2. Open-VSX

For Theia, one challenge is to maintain a certain compatibility with the VSIX format. So I'd prefer a solution that is orthogonal to the VSIX format. That being said, in custom Theia-based tools, using a customization, we could (and has been done afaik) enforce installation checks by providing a list of verified extensions (e.g. ID+checksum) and ensure only those can be installed.

For Open-VSX, it could make sense to align with open-vsx. In open-vsx there is also the concept of verified publishers.
Also, there is a great talk by @MatthewKhouzam related to this topic: https://www.youtube.com/watch?v=fFMBWjV-wBo