A browser RPC key and a server-held secret have different exposure boundaries. The old Infura note considered rate limits, allowed origins/contracts, API-key secrets, and signed JWTs. Its example quotas were configuration choices, not current plan limits.
Basic authentication is encoding, not encryption
curl --user :<INFURA-API-KEY-SECRET> \ https://mainnet.infura.io/v3/<INFURA-API-KEY> \ -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'Header { Authorization: Basic base64(':<INFURA-API-KEY-SECRET>')}The secret in Basic authentication must stay on the trusted side of the application. Base64 does not hide it, and embedding credentials in a URL can expose them through logs or copied links. That URL pattern is omitted from the old note. Origin and user-agent restrictions are also not equivalent to secret authentication for arbitrary clients.
JWT signing belongs on a trusted signer
The source registered a public key with the provider and used the corresponding private key to sign tokens. A frontend can receive a narrowly scoped, short-lived token; it should not receive the private signing key or reusable server secret.
HEADER:
{
"alg": "RS256",
"typ": "JWT",
"kid": "<JWT-ID-GENERATED-BY-PUBLIC-KEY>"
}
* Where:
- Use a supported algorithm (RS256 or ES256) and declare it in the alg header field.
- Specify JWT in the typ header field.
- Include the JWT ID (NOT project API key) in the kid header field.
PAYLOAD:
{
"exp": "1958812021",
"aud": "infura.io"
}
* Where:
- Have an unexpired exp timestamp in the payload data. https://www.freeformatter.com/epoch-timestamp-to-date-converter.html
- Specify infura.io in the aud field.The original payload writes exp as a quoted string. JWT defines it as a NumericDate value; this historical shape should not be copied as a validated token. The audience, expiry, algorithm, and key identifier must match the verifier’s actual requirements. The kid selects a key; it is not a replacement for signature verification.
Header { Authorization: Bearer <Encoded JWT Token>}The source’s flattened key-generation commands and commands that print private-key material are omitted. Public online JWT tools should not receive a real private signing key. This revision did not generate a key, create a token, or call an RPC endpoint.
The provider integration note records the older Web3/Truffle side. Reference: JWT claim definitions.