New API Authorization requirement and options for Open Source projects

[calebcartwright]

Greetings :wave:

I'm one of the maintainers of the Shields.io and we've offered dynamic badges to users of your service for some 3+ years by utilizing your API (refs #https://github.com/badges/shields/pull/3929, https://github.com/badges/shields/pull/3958).

It seems there's been some recent changes in the API which now require authorization via a paid API key which has in turn broken our ability to integrate with the API to fetch the data we need to provide these badges (https://github.com/badges/shields/issues/9154) .

I'm reaching out to see if there are any viable paths forward for us to be able to resume consumption of your API to be able to continue providing these badges, or if we'll need to drop them.

For context:

Shields integrates with the APIs of hundreds of services, plenty of which similarly require authorization, and we have a couple of patterns for dealing with this. We typically prefer to collaborate with the maintainers of the service to find a path forward both to ensure we're being good citizen consumers, and also to figure out an auth mechanism we can use that eliminates, or at least minimizes, the impacts on our users.

This often takes the form of the Shields maintainer team setting up an account with the service, obtaining the auth mechanism (token, key, creds, etc.), which we then incorporate in the Shields.io runtime environment. However, from what I can tell that model would be challenging here both because of our request volume (seems we're making about 1k requests/day) and because of the cost (we're a FOSS project that lives on donations, and we definitely can't afford to pay to get data).

The other alternative we have is to shift the auth mechanism out to our end users wherein the auth mechanism has to be passed to us when users request a badge from us (as a URI path or query string), i.e. our users would historically request a Security Headers badge via https://img.shields.io/security-headers?url=https://google.com and we'd add a new required param for users to provide their own API key, e.g. https://img.shields.io/security-headers?url=https://google.com&key=abc123def456, which Shields.io would in turn use when making the request to the Security Headers badge (in case it's helpful, here's a really rudimentary visualization of the badge process flow where the "data provider" actor in this case is your API)

However, we're not terribly fond of that latter approach for various reasons and typically look to it as a last resort. Even then we'll only consider it in cases where it's possible for the auth mechanism to be generated in a scoped, read-only type of manner. We do this because badges are embedded in project readmes, websites, etc. where the badge url is available in plaintext, thus making the auth details pretty widely exposed.

Correct me if I'm wrong, but my assumption is that Security Header API Keys are only scoped to the owning account, and can be utilized for any target site/endpoint. If that's indeed the case, this would be a non-starter for us because the API key owner would be fully giving away their key (and scan quota) if they tried to use it with our badges.

As such I feel like our only plausible option would be for the Shields project to get an API key that we could use internally, but that still has the challenge of request volume and costs.

Please let us know your thoughts, if you have any questions or there's anything above that's confusing/unclear. Also willing to continue the conversation in private over e-mail if you'd prefer.

Thanks in advance!

[ScottHelme]

Hi @calebcartwright,

It seems like your service is free to use so I'm sure we can work something out. Please email me directly (scott@ our domain) and I'll take a look at what your needs are!

[calebcartwright]

Hi @calebcartwright,

It seems like your service is free to use so I'm sure we can work something out. Please email me directly (scott@ our domain) and I'll take a look at what your needs are!

Thank you! We'll reach out soon

[iansantagata]

Hi @ScottHelme and @calebcartwright -

I'm a user of Shields.io and have my own set of FOSS repositories that utilize Shields.io that are impacted by this issue.

Are there any updates here related to discussion around this issue or means of addressing it?

Curious if there is a resolution that I may have missed or it was posted somewhere else (outside of GitHub) that I may not have been aware of.

Thanks in advance for the assistance!

[ScottHelme]

I don't believe I got an email from @calebcartwright, or at least, I can't find one!

I'd be happy to get something moving here Caleb, shoot me an email.

[sbernard31]

Hi, All any news about this ?