Hacker News 中文摘要

文章摘要

文章批评了传统API密钥生成流程的繁琐，并展示了如何通过简单的代码生成自签名的JWK（JSON Web Key）作为API密钥，从而简化流程，避免复杂的注册和配置步骤。作者认为这种方法更为高效，且无需区分客户端和服务器端的密钥。

文章总结

自签名JWT的便捷性

在开发过程中，许多开发者习惯于通过繁琐的步骤获取API密钥：创建账户、验证邮箱、添加信用卡、生成API密钥等。然而，生成自签名的JWT（JSON Web Token）实际上非常简单，无需这些繁琐的步骤。

生成自签名JWT

使用jose库，只需几行代码即可生成JWT密钥对：

```javascript import { generateKeyPair, exportJWK } from 'jose'

const keyPair = await generateKeyPair('ES256', { extractable: true, }) const publicKeyJWK = await exportJWK(keyPair.publicKey) const privateKeyJWK = await exportJWK(keyPair.privateKey) ```

这样，生成的JWK密钥对就可以作为自签名的API密钥使用，省去了传统获取API密钥的复杂流程。

如何使用自签名JWT

通过自签名JWT，可以简化客户端和服务器端的密钥管理。以下是一个简单的实现步骤：

存储私钥：将应用的私钥存储在服务器端。
授权函数：根据现有的认证方案，实现一个函数来判断是否允许执行某个操作。
JWT声明：将特权操作作为JWT的声明（claims），如果允许执行特权操作，则在JWT的payload中包含该声明，并使用私钥签名。
客户端代理：在客户端SDK中实现一个函数，将请求反向代理到API，并在请求的Authorization头中添加签名的JWT，包含所需的特权声明。

客户端生成JWT的示例代码如下：

```javascript import { SignJWT } from 'jose'

const jwt = await new SignJWT({ destroyDatabase: true, // 特权操作声明 }) .setProtectedHeader({ alg: 'ES256', jwk: publicKeyJWK }) .sign(privateKeyJWK); ```

收费API的实现

如果希望通过API收费，可以在请求使用未付费账户的公钥时，返回一个支付URL。客户端SDK可以将该URL展示给开发者（例如通过控制台输出）。开发者支付后，将该公钥与付费账户关联，并停止返回支付URL。

B2B2C场景下的应用

在B2B2C（企业对企业对消费者）场景中，开发者可能希望为其终端用户提供API密钥。这时，可以采用分层JWK派生方案：

主JWK：开发者创建主JWK。
派生子JWK：为每个终端用户从主JWK派生子JWK。
零知识证明：在JWT方案中，包含一个零知识证明，证明终端用户的密钥是从开发者的主公钥派生的。

这样，可以验证终端用户是否由特定开发者授权，而无需开发者管理每个用户的API密钥。

通过自签名JWT，开发者可以简化API密钥的管理流程，提升开发效率。

评论总结

评论内容总结：

JWT的实用性与资源推荐
- 评论1提到GitHub和JWT.io提供了有用的JWT生成资源。
  - 引用："Github has a cool little article on making JWTs for their API. Very useful!"
  - 引用："The JWT website is also super useful."
JWT的安全性问题与替代方案
- 评论2指出JWT的JOSE标准存在安全隐患，推荐使用PASETO作为替代方案。
  - 引用："This article is giving the developer lots of rope to hang themselves with the JOSE standard."
  - 引用："PASETO is a much better alternative to work with."
- 评论3质疑允许客户端设置自己的claims是否安全。
  - 引用："is the author suggesting allowing the client to set their own claims? That sounds fraught with risk."
JWT与API Key的比较
- 评论5认为JWT并未简化API Key的管理流程。
  - 引用："None of this 'BS' actually goes away with self-signed JWTs."
- 评论9指出JWT在API认证中的优势，但认为其使用门槛较高。
  - 引用："JWTs represent a huge usability hit over API Keys for the average joe."
JWT的适用场景与目标受众
- 评论6质疑JWT的目标受众，认为其描述的场景不明确。
  - 引用："I feel like I’m not understanding the target audience for this post."
- 评论7提到类似GitHub的公钥注册模式，认为其可行。
  - 引用："Sounds like what we already do with GitHub. I like it."
JWT与其他认证方式的比较
- 评论8将JWT与Passkeys类比，认为两者在用户提供的认证令牌方面相似。
  - 引用："The model here feels not entirely dissimilar to Passkeys?"
- 评论11建议使用OAuth作为更常规和安全的解决方案。
  - 引用："Wouldn’t a standard OAuth flow be the more conventional and secure solution?"
JWT的易用性与实现难度
- 评论10认为JWT的实现并不复杂，质疑使用JavaScript库的必要性。
  - 引用："I don’t know why anyone would install a JavaScript library to do this."
- 评论12质疑JWT的易用性，认为其可能存在未提及的缺点。
  - 引用："Surely there must be a catch somewhere right?"

总结：评论中对JWT的实用性、安全性、适用场景和易用性进行了广泛讨论。部分评论认为JWT在API认证中具有优势，但也指出其存在安全隐患和使用门槛较高的问题。同时，PASETO和OAuth被推荐为更安全的替代方案。

自签名JWT -- Self-Signed JWTs