OAuth authorization screen is misleading for GitLab-owned application
## Problem to solve There are a number of severe problems with the OAuth screen for GitLab-owned applications such as the VS Code extension, glab, etc... #### Incorrect information For applications that we created and actively maintain, the **OAuth screen states that this application is not provided by GitLab, which is factually incorrect**. | CLI | VS Code extension | | ------ | ------ | |![image](/uploads/3f036bd345129b0068502283d42055d2/image.png)|![image](/uploads/7ff2c0b9e692498524445e6d1e05ec16/image.png)| #### Broken links **None of the links** that should lead to details about the application **work**. | CLI | VS Code extension | | ------ | ------ | |![image](/uploads/1acaefb5b2e7c0255335749139c65267/image.png)|![image](/uploads/557742ff9bc01be3b71761fab7580fd6/image.png)| |![image](/uploads/0d0a67d63b260f408800237b38bff152/image.png)|![image](/uploads/7f2976d17909cc0ed3a7dede5754a538/image.png)| #### Incorrect usage of color The "Authorize" button in this screen is red. Our [color usage](https://design.gitlab.com/product-foundations/color#red) and [button variant](https://design.gitlab.com/components/button#variants) guidelines in Pajamas state the following cases for the use of a red color for a button: > Highlight an action that is destructive and undoable or has potentially detrimental consequences. While there could be an argument made for "potentially detrimental consequences" by authorizing community-created applications, this **should not be the case if this is a GitLab-owned application**. #### No way to identify misleading/fake applications **If I were to use my personal account and create an extension** that I called "GitLab CLI" and used the same scopes, the **OAuth screen would look exactly the same** as the screen for our official tool. There is 0 information in this screen that users could use to determine the author of the tool, or any other important information. ## Potential solution There are multiple levels/steps that we will need to take here: The two most important ones are: 1. **Solve the existing bugs** on this screen. 2. Identify ways to **differentiate verified GitLab-owned** applications. If we want to look at general improvements that could also solve the second part from the list above, I would consider reframing that second step as following. 2. Come up with ways to **give users more information about application and author** to determine whether they can trust it. Giving users more information about application and author could also already give them enough input whether it's a GitLab-owned application, while also making the flow and screen better for community-owned applications.
issue