Recap: REST Authentication and HTTP Signatures
A brief summary of the talk by David Blevins titled “Deconstructing REST Security by David Blevins”
This is a brief summary of this talk (2017).
Summary
The speaker covers 4 styles of REST security: Basic Auth, OAuth2 with access tokens, OAuth2 with JWT, and HTTP Signatures.
For Basic Auth, other than sending credentials in (almost) plaintext, architecturally there is also a terrible performance impact against LDAP server (or the auth server) which has to handle the calls to verify the credentials. The speaker also alluded to lack of zero-trust security within the BE services as any APIs can be called without further authorization.
For OAuth2 using access tokens, the speaker gave a brief summary of the auth code grant and refresh grant types and states that the outcome is that “you have more passwords”. Tokens are essentially passwords that can be intercepted and is actually no different from HTTP session ID. In terms of performance, although there is a reduced impact on LDAP server, the impact is now on the OAuth2 authorization server who has to respond to calls resolving the access token. The speaker also noted that a lot of the OAuth spec is optional, such as refresh token grant. If the refresh token grant is not implemented, the access token is effectively a password because it cannot be re-issued without the user logging in again.
Instead of access tokens, we could also use OAuth2 with JWT. The speaker talks about the benefits of JWT, and of using OAuth2 with JWT: the client holds their own state and therefore there is lesser performance impact on the authorization server. The JWT can/should also be propagated to services that need to verify the JWT. “We have achieved stateless REST security”.
We next talk about HTTP Signatures, in which the caller signs a “signing string” for the server to verify. The client/service can choose which headers to sign, but the “Date” header is encouraged to prevent replay attacks. However, each hop in the microservices chain will need to re-sign its own HTTP message so there might be an issue with propagating user identity. One solution is to combine OAuth with HTTP signatures using symmetric keys: systems that need to talk to each other will maintain a shared symmetric key with which to sign/verify HTTP signatures.
The closing note is that “digital signatures is driving security in the modern day for REST”.
Observations and thoughts
- The latest iteration of the IETF document on HTTP Signatures seems to be https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-09 (2022), which is much more fleshed out than the version shared by the speaker (and much closer to 100 pages).
- Interestingly, the payload/body of the HTTP request is not mandated/encouraged to be in the signing string.
- This concept sounds the same but seems to be slightly different than the fairly common concept of API request signing, which signs the request body (or the query params) and append the signature into the url query param. An example: https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
- An interesting quote on OAuth with access tokens: “We haven’t achieved much other than exchanging a lot of passwords a lot more frequently”. Indeed, with the token containing the state (or is exchangeable for state), it becomes the password
- Something which I found confusing was that Basic Auth and passwords, which are authentication schemes, are being compared against OAuth which is an authorization scheme. HTTP signatures, as described, also seems like an authentication scheme to me. So perhaps what was being referred to as “OAuth” is the OpenID Connect (OIDC) layer? At some points the term “user identity” is also mentioned, which would align with the ID token.
Some other articles you might like
