Implementing GitHub-like "Personal Access Tokens"

Hello, everyone!

I'm reaching out to the community for insights on a scenario that I initially thought was common, but I'm struggling to find examples or guides. Perhaps my assumptions were off, or I might not be using the right search terms.

Here's our situation: We're in the process of meticulously designing a robust Authorization and API framework using Entity Framework for our customers. However, this is a time-consuming process, and we're concurrently preparing to launch an MVP for our product.

To add immediate value for our users, especially in a dev/infra SaaS context, we're considering implementing a feature for users to generate long-lived access tokens. These tokens would be used in their scripts and automation tasks. The most notable implementation of such a feature can be found in GitHub.

The envisioned user flow is as follows:

1. The user navigates to their profile.
2. They access a specific section dedicated to API integration.
3. Upon clicking "Generate Personal Access Token," they see a token that can be easily copied.
4. The user can then use this token for API interactions, with actions being internally authorized via FusionAuth. Additionally, there's an option to revoke or delete the token as needed.

Our rationale behind this approach is to establish a straightforward Proof of Concept (PoC) for API authorization. This allows us to hit the market sooner, while gradually evolving our API authorization infrastructure to be more sophisticated over time.

I'm keen to know if anyone has implemented a similar feature using FusionAuth. Any examples, recipes, or best practices would be immensely helpful.

Thanks in advance for your insights!

@mark-robustelli Thank you for your answer. Indeed, we are considering this option as a last resort. Because Application Authentication tokens are "replacement" for passwords. It is not enough to provide only this token to identify the user, and login identifier should be provided alongside. It is somehow different from reference GitHub implementation.

@mark-robustelli yes. We even tested it. However, the ideal case for end users would be to provide a single token for API calls. But passing Authentication Token to Login API requires to specifying user login (in our case, email). Here is an example request from documentation.

{
  "loginId": "example@fusionauth.io",
  "password": "52h3h9fsjOn2Eh0+NBT3Kf6NcWFHbJ7oPD0sFsHMQps=",
  "applicationId": "10000000-0000-0002-0000-000000000001",
  "ipAddress": "192.168.1.42"
}

@mark-robustelli Thank you. It is an interesting workaround. I think if we apply encryption on top of the generated string value, it will not disclose user's login.