search

camaraproject / QualityOnDemand

Repository to describe, develop, document and test the QualityOnDemand API family
https://wiki.camaraproject.org/x/zwOeAQ
Apache License 2.0
42 stars 59 forks source link

Ensure secure handling of callback URL #31

Closed shilpa-padgaonkar closed 10 months ago

akoshunyadi commented 1 year ago

To solve the issue about the unsecure callback I propose to use oauth2 instead (!) of the current api-key. It means we would need new parameters (maybe in a substructure): Client-id, Client-secret and Access token URL. Any comments?

eric-murray commented 1 year ago

@akoshunyadi So your proposal is that an API provider get and manage an OAuth2 key from each and every API caller that might use the API? And this key would be transferred separately from the API. Maybe if the API caller is a large aggregator (like Ericsson), then that might be reasonable. But for smaller organisations, it might be challenging to expect that.

So that could be one option, but it should not be the only option.

Rather, we should also allow the API caller to optionally just provide a token. If they are not concerned about security, that could be a static or even blank token. If they were more concerned about security, it could be an OAuth token with limited lifetime. Nonetheless, the API implementor just uses that token (or no token) in the callback, and the API caller deals with generating and managing the token.

I think we would be fooling ourselves if we think the contents of API notifications are particularly secret. The API caller should decide on their own risk tolerance.

jlurien commented 1 year ago

There is an open issue in Commonalities to discuss the Subscription/Notification model across all APIs, and security aspects is also something we should probably agree on.

akoshunyadi commented 1 year ago

We could also keep the current api-key and add the additional security. Currently the notification content is really not so important, but I'm thinking of future events also in other APIs with sensible data.

chrishowell commented 1 year ago

I think mandating all notification recipients implement OAuth flows is a super bad idea, it's way outside the resources that some developers have available to them.

It would be nice to have centralised management of notification servers though, perhaps each having a different set of access credentials, which could be OAuth, or just Bearer. I think this belongs in Commonalities though, rather than QoD.

hdamker commented 1 year ago

@chrishowell yes, discussion is happening in Commonalities and everyone is encouraged to support there with reviews and contributions. We will continue here when the guidelines are updated.

hdamker commented 10 months ago

This issue is be done, current v0.10.0-rc is following the design guidelines for notifications as defined by Commonalities v0.2.0. If there are additional security requirements by Commonalities we need to open a new issue.