search

airyhq / airy

💬 Open Source App Framework to build streaming apps with real-time data - 💎 Build real-time data pipelines and make real-time data universally accessible - 🤖 Join historical and real-time data in the stream to create smarter ML and AI applications. - ⚡ Standardize complex data ingestion and stream data to apps with pre-built connectors
https://airy.co/docs/core
Apache License 2.0
369 stars 44 forks source link

Allow API key authentication on all endpoints #1036

Closed chrismatix closed 3 years ago

chrismatix commented 3 years ago

Current state To authenticate with APIs users have to obtain a short-lived JWT token (docs), which is intended for UI use cases. However for automation use cases it is common to issue a permanent API key.

We already have a value for API keys on the webhook data model and APIs, but so far you cannot do anything with the key.

Desired state Users can generate and use an API key for interacting with all APIs.

Implementation proposal Since it's unfeasible that we can have a store for webhooks everywhere, we should remove that concept from webhooks. For a first version, it is perhaps best if we do not store the API key at all and instead generate it during bootstrapping and add it as a default variable to the airy.yaml file.

Then users can set the API key on the Authorization: Bearer $TOKEN header which will be checked as in the authenticator in the JwtAuthenticationFilter in the spring-auth package using an environment variable from a config map.

steffh commented 3 years ago

maybe we should adopt https://tools.ietf.org/html/rfc6750 for Bearer token usage and https://tools.ietf.org/html/rfc7523 for JWT bearer token usage instead of using a custom header for authorization?

lucapette commented 3 years ago

We should probably provide a UI for this? I think short term the easiest way out is a CLI command. But I'd also love to see this in the UI

chrismatix commented 3 years ago

@steffh Yes we can use rfc6750 for sure. Practically it would only mean that both the jwt and the access token get passed via the bearer auth header. rfc7523 seems unrelated unless the idea is to introduce OAuth2.0. In either case, I would move that discussion to a different ticket perhaps in the cloud repository.

@lucapette I agree. We could create a follow-up ui ticket once we remove the discussion label on this one.

chrismatix commented 3 years ago

@lucapette if it's ok with you I would track the UI work on a follow-up ticket with the requirements that users can set an API key in their airy.yaml and that we check for it on the Auth bearer header.

steffh commented 3 years ago

Yes @chrismatix - I agree, also the UI for the webhooks is really undercomplex still. If it's no / almost no work to bring the old "webhook UI", we can do that of course.

In the long run we'll rather need an app management / app marketplace kind of experience there, so a place where people can manage multiple integrations instead of just one webhook.