Interesting, so instead of OpenAI giving me an API key, I give them a public key, which they register. Sounds like what we already do with GitHub. I like it.
Which, unless I'm missing something, undercuts the entire article? The private key, in the generated keypair, is the thing that you can then never commit to your VCS.
When you "register" the public key with whatever the relying party is, you're also likely going to bind it to some form of identity, so you can't leak this private key to others, either. (And I'm curious, of course, how the relying party comes to trust the public key. That call would seem to require its own form of auth, though we can punt that same as it would be punted for an API key you might download.)
> Sorry, are you expecting some way to authenticate without any secrets?
I'm not. "It’s truly wild to me what some of y’all will tolerate." What, exactly, are we tolerating that is solved by asymmetric key pairs?
> The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.
Well, then, I'm lost. What back & forth was eliminated?
In one system, we download an API key. In this system, we upload a public key. In both, we have a transfer; the direction doesn't really matter. Someone has to generate some secret somewhere, and bind it to the identity, which is what I was saying above, and is apparently the wildness that I'm tolerating.
Yes but when you have to do this 13 times, it gets really annoying to manage all those API keys. Especially if you need them in different processing contexts. If I could just have a single public/private key pair for my app it would simplify managing all the extra services I use.
Thank you! I suppose yes, that it would amortize a few steps. (But as I mention in another comment, that only amortizes the management of the secret portions, which is a small portion of the objected to "insanity".)
> Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Create an API key. Add it to your password manager. Drop it in your .env file. Download our SDK. Import it. Pass your env var in.
This is the pitch. But it seems like you fixated on the next part of the paragraph where it talks about api keys in version control.
I’ll agree with you in as much as this isn’t a massive change - but i like the approach for being an incremental improvement - and for challenging the status quo
Let's say instead of downloading API keys, everyone on the Internet permits uploading a public key to represent a service. Now it's: Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Upload an API pubkey. Download our SDK. Import it.
All of that seems unchanged by using a pubkey to represent programmatic access.
(And as a sibling comment more constructively notes, you might be able to combine pubkeys, so, "Add it to your password manager. Drop it in your .env file. […] Pass your env var in.", but potentially only once. So we can omit that part here, I suppose.)
In theory, I as the service provider know when my key database has been compromised. In theory. In practice, I will never know if a customer has been compromised, however up to a point a compromised user box can forward tokens to an attacker. So pending on whether you ever rotat the private keys, it’s a matter of ho long an attacker can retreat to a server they own to continue the attack.
In a way this reminds me a bit of SRP, which was an attempt to handle login without the server ever having your password. Which makes me think this is something to be integrated with password managers.
Even better: Imagine a world where you could just host your public keys on e.g. mydomain.com/.well-known/jwks.json, you register with a service provider with me@mydomain.com, then the service automatically pulls public keys from that. Then, all you have to do is sign new keys with an appropriate audience like aud:"serviceprovider.com".
And for the public email providers, a service like Gravatar could exist to host them for you.
and it’s easy to do keypair generation in the browser using subtle crypto. That API doesn’t provide jwk generation, but seems like it would be relatively easy to do even without the jose module. And the browser cab “download” (really just save) the keypair using the Blob API. Keys need not leave the browser.
An api developer portal could just offer
- generate a new keypair?
- upload your existing public key?
…As a choice. Either way the public key gets registered for your account.
This is actually how GCP has always done service account authentication. A GCP service account key is an asymmetric keypair and Google stores the public key. AWS is somewhat similar, but they use an symmetric HMAC so they store the same secret key you use.
It's interesting to imagine taking the pubkey as identity concept to its full extents in situations like this, for example if you could create a cloud account, spin up resources, and authorize payment for them all programmatically without having to enter payment details on a form (because your keypair can authorize payment with the whatever payment method you use)
