The neat thing about JWT is that there are no secrets to scan for. Your secret material ideally lives inside an HSM and never leaves. Scanning for these private keys is a waste of energy if they were generated inside the secure context.

▲

agwa 2 days ago | parent | next [-]

But JWTs are usually used as bearer tokens when doing API authentication. Those are definitely secrets that need to be scanned for.

Or are you suggesting that the API requests are signed with a private key stored in an HSM, and the JWT certifies the public key? Is that common?

	▲	bob1029 2 days ago \| parent \| next [-]
		> are you suggesting that the API requests are signed with a private key stored in an HSM, and the JWT certifies the public key? Is that common? Very. The thing that certifies the public key is called a JWK. https://datatracker.ietf.org/doc/html/rfc7517 This is typically hosted at a special URL that enables seamless key rotation and discovery. https://auth0.com/docs/secure/tokens/json-web-tokens/json-we...
	▲	mattacular 2 days ago \| parent \| prev [-]
		That's how JWT is designed to work

▲

vjay15 2 days ago | parent | prev [-]

Ideally API key shouldn't contain anything regarding the account or any info right? it's meant to be an opaque string, is what I found in most of the other articles I read. Please do let me know if I am wrong about this assumption

	▲	ijustlovemath 2 days ago \| parent \| next [-]
		JWT operates on a different principle; the user's private key (API key) never leaves the user's device. Instead, the stated "role" and other JSON data are signed with the servers pubkey, then verified by the server using its master key, granting the permissions that role allows.
	▲	miningape 2 days ago \| parent \| prev [-]
		Look at the JWT standard, it usually contains things like claims, roles, user ids, etc.