3

For securing REST APIs, a logical choice for access control is JWT either by itself or in combination with OAuth. If I only care about authenticating the caller, verifying a JWT signature is sufficient by itself. If I also care about authorization, I would also use OAuth, or some kind of token service. Either way I am including a header like Authorization: Bearer [JWT token] in the HTTP request.

AWS has its own standard for API access control where you sign parts of the request itself and include a header like Authorization: AWS4-HMAC-SHA256 ....

My questions:

  • is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

  • if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

3

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

Yes, it is more secure against replay attacks. As you suggested Bearer tokens can be used with any request (not just theoretically). They are completely independent of the request they authorize. AWS signatures, on the other hand, are "bound" to the request they are attached to. The request signed also contains a timestamp that is checked by AWS to make sure it is within a certain window. The request can only be replayed in this window.

Just as you said, the signature ensures the integrity of the request. Integrity is also provided by HTTPS. The AWS scheme maintains integrity even if HTTPS is taken away.

if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

It does give you more security properties. There are some other HTTP signature schemes that try to replicate what AWS does. Here is a draft. Joyent also created their own scheme. There is also a library called Escher, which completely replicates the AWS scheme. It is also compatible with it and includes the validation side as well.

DISCLAIMER: I work for the company who developed Escher. We use it in production to connect lots of services.

1

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

All the requests that are sent using the API have a timestamp associated to them. AWS rejects requests that were received more than 5 minutes after the timestamp. For the replay within the 5 minutes, they can simply maintain a sliding window of cached requests. It can match the hash against the one in cache and detect replay.

if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

If you are talking about the basic concept of hashing a request and sending the hash along with the request, it is something that is already being done. I feel that the system that Amazon uses here is inspired by the Kerberos system which has a similar mechanism of detecting replay attacks and the idea of hashing the request and attaching it to ensure that it is not tampered on the way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.