feat(APIKeys): API key generation and management when OIDC is enabled

[aaldebs99]

Summary

Fixes #1055

This PR aims to implement API key creation and management when OIDC is enabled.
Currently, there is no programmatic way to access the API without going through the OIDC flow.

Key features:

• UI management
• User-Scoped API keys
• Optional config entry to enable/disable API key management security.apikeys-enabled: bool
• Storage in sqlite, postgres, and memory supported

Before I continue with unit tests, documentation, and further testing, I wanted to see if this is an approach the maintainers would be open to and interested in.

Checklist

• Tested and/or added tests to validate that the changes work as intended, if applicable.
• Updated documentation in README.md, if applicable.

[aaldebs99]

@TwiN I would love your opinion on this. Is this an approach you would like to see or can something be done differently? The feature does build and run if you would like to give it a try

[TwiN]

This and #1055 are two completely separate issue. #1055 is about not having a way to using OIDC for programmatic access, while this seems to be implementing a complete API key management system.

While I do appreciate your effort, this isn't something I want to support (even though your implementation on the UI side makes Gatus look even cuter!). Instead, besides adding support for OIDC token at the API level, I wouldn't mind having support for a list of tokens that can be used to access the API.

This is consistent with the existing approach (i.e. token field for external endpoints), and should also require far less changes that a complete API key management system.

[aaldebs99]

This and #1055 are two completely separate issue. #1055 is about not having a way to using OIDC for programmatic access, while this seems to be implementing a complete API key management system.

While I do appreciate your effort, this isn't something I want to support (even though your implementation on the UI side makes Gatus look even cuter!). Instead, besides adding support for OIDC token at the API level, I wouldn't mind having support for a list of tokens that can be used to access the API.

This is consistent with the existing approach (i.e. token field for external endpoints), and should also require far less changes that a complete API key management system.

Ah I see what you mean, yea I took the "ignore OIDC token" approach and use API keys so in a way this is different from the issue, but it would still kind of be a workaround.

What would your idea of list of tokens that can be used to access the API look like?

[TwiN]

Something like

security:
  api:
    tokens:
      - 12345
      - abcdef

Where the token is explicitly defined and left to the user's choice (in that we're not enforcing a specific format for the token).

Those tokens would effectively give full read access on the API, bypassing OIDC/basic auth.

[aaldebs99]

Something like

security:
  api:
    tokens:
      - 12345
      - abcdef

Where the token is explicitly defined and left to the user's choice (in that we're not enforcing a specific format for the token).

Those tokens would effectively give full read access on the API, bypassing OIDC/basic auth.

Interesting, that is certainly simpler…
I personally would prefer my approach but I completely understand if you don’t wanna support the extra overhead. From a security perspective (not that it matters too much here) it’s much better to generate those and not have them saved in config or environment variables. I’m a pentester so that approach immediately fires alarms in my mind LOL

I ask that you think it over but again, no pressure and I completely understand if you don’t wanna support it.

I can make your approach happen in the meantime if you’d like?

[TwiN]

I understand your concern wrt security, but this is also something I came to terms with a while ago. People have to write webhooks, secrets, email passwords, etc. in Gatus' configuration, and if they trust the configuration file enough for that, I'm not particularly worried about readonly tokens.

If they really want something a bit more secure, they can use environment variables and mount the secrets on deployment.

[aaldebs99]

I understand your concern wrt security, but this is also something I came to terms with a while ago. People have to write webhooks, secrets, email passwords, etc. in Gatus' configuration, and if they trust the configuration file enough for that, I'm not particularly worried about readonly tokens.

If they really want something a bit more secure, they can use environment variables and mount the secrets on deployment.

That’s fair. Now the million dollar question, would you be okay with BOTH options or do you absolutely not want to maintain the UI API generation?

[TwiN]

I absolutely do not want to maintain API management on the UI. For now, at least.

I'm very impressed with your work, that's not the issue. My concern is more maintenance wise for me, e.g. what do we do about memory storage? Restarting the app would wipe the api keys created. I'm not at home at the moment and I can elaborate further if you want me to later.

[aaldebs99]

Gotcha, no worries at all! I completely understand.
I did think about the memory storage and I don't have a solution lol

I respect that you want to keep it all contained within the config yaml.

I can go ahead and close this PR and implement your approach instead 👌