I am trying to achieve an authentication system that:
- Has short-lived passwords/tokens (unlike Basic Auth or Api key),
- Won't expose users credentials if my users table is leaked (unlike HMAC),
- Every request to the API can be achieved with just one call to the server (unlike schemes with a refresh token).
I understand the OpenID/OAuth flows, where an authorization server generates the JSON Web Token (JWT) that a client can use to authenticate to access a resource.
I am considering a flow where the client generates and signs their own JWT:
- The user generates a private-public key pair, and registers the public key in the API server.
- The client creates a JWT with a claim with the accountId provided by the API server and an expiry claim (eg 1 minute from now).
- The client signs the JWT using one of the asymmetric algorithms and the private key.
- The client sends a request to the API server using the JWT.
- The server extracts the accountId claim from the JWT, and looks for the registered public key for that accountId in the database.
- If the signature of the JWT can be verified against the public key, the authentication succeeds. Otherwise, it fails.
The only trade-off (I think) is that each authentication needs a call to the DB to retrieve the account's public key. This is not an issue for us.
What are the security considerations or trade-offs of a scheme like that?