Avoid users having to authorize OAuth authentication when using Remote Development

Problem

The Remote Development feature is reusing OAuth authentication. While that made it possible to get to an MVC faster, it also has a significant impact on the user experience and creates multiple problems as well as blocking us from further potential improvements.

Behaving and feeling like a third-party solution

GitHub Codespaces does not require the user to authorize any OAuth application. Our behavior is more similar to third-party solutions, like Gitpod. This is a problem as we are forfeiting our unique differentiator of being "one DevSecOps platform" when it comes to the user experience.

Potential adoption barrier

It can also become a barrier to adoption, as we intentionally have a very visible warning on the OAuth screen (Make sure you trust this application before authorizing) and it's a very unusual pattern to have to authorize the platform to do something for a native feature, that already should have full access to the information that is requested here, so users might hesitate or even decide to not authorize.

Contributing to a very complex setup process for admins

One of the major challenges for adoption Remote Development is the initial setup. As we try to make it as flexible as possible while giving customers complete ownership over their infrastructure, we also push a lot of responsibility and work on their administrators. For the OAuth flow, that means that they have to create their own application, configure it correctly, and then also use the resulting client id and secret for further steps of the setup, instead of us offering them more of a "works out of the box" or at least a more "guided" experience.

Potential solutions

It was already the alignment 1 year ago that we should not use OAuth as long-term solution, so moving to another technique that gives us more control over the flow and doesn't require us to expose these aspects to the user should still be the way forward. See #471856 (comment 2013133339)

For making progress on these aspects without investing heavily into this, we could also try to find ways to just hide these moments as much as possible from the users and make them happen automatically in the background. How much of that is actually possible and whether that's a smaller investment than moving towards JWT would have to be investigated.