Unclear Personal Access Token Creation and Usage in Workspaces
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem
When using Remote Development, at no point do we make the user aware that as part of a workspace creation process, an access token will be created. However, there are multiple moments where the user is afterwards getting exposed to this access token, which creates multiple problematic situations:
Concern about compromised account
Once you used Remote Development for the first time, you will get the following email after the workspace and associated access token has expired. As the user has not been made aware anywhere in the previous flows that as part of his usage of Remote Development an access token with a very short expiration time has been created automatically for them, we have already seen that some users become scared about their account having been compromised.
Potential to destroy workspace without being aware
If you are not aware of the connection between access tokens and Remote Development, you might happen to revoke an access token while still having the associated workspace running. If that's the case, there is no chance to recover and repair the working session, and you will only notice that something is wrong once you try to push, which will fail without a clear explanation.
Overload of notification emails
With Remote Development enabling users to having multiple workspaces running next to each other, and creating new ones multiple times each day. That behavior of treating workspace as short-lived is also something that many competitors officially encourage as best practice.
However, with our connection to access tokens, that means that in the next days, users will get at minimum one email per workspace they created, to make them aware that the connected access token is now expired.
How our competitors solve this
Neither GitHub Codespaces nor Gitpod require any kind of access token authentication anywhere in the flow. So even though our Remote Development feature is native, it behaves and feels more like a third-party solution than actual third-party solutions.
Potential solutions
There was alignment 1 year ago that we should not use access tokens as authentication method as long-term solution for Remote Development, but to get an MVC as soon as possible, using access token was chosen as short-term workaround.
If we still see JWT as the correct long-term solution, we have two potential paths:
- Move towards JWT
- Continue using access tokens, but hide it from the user and prevent any user interaction with them