Authentication

#Introduction

RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.

Challenge

In security protocols, a challenge is some data sent to the client by the server in order to generate a different response each time. Challenge-response protocols are one way to fight against replay attacks where an attacker listens to the previous messages and resends them at a later time to get the same credentials as the original message.

Replay attack

In web security, a replay attack happens when an attacker intercepts a previously-sent message and resends it later to get the same credentials as the original message, potentially with a different payload or instruction.

Replay attacks can be prevented by including a unique, single-use identifier with each message that the receiver can use to verify the authenticity of the transmission. This identifier can take the form of a session token or “number used only once”

#Challenge-response flow

The challenge and response flow work like this:

1. The server responds to a client with a 401 (Unauthorized) response status and provides information on how to authorize with a WWW-Authenticate response header containing at least one challenge.

2. A client that wants to authenticate itself with the server can then do so by including an Authorization request header with the credentials.

3. Usually a client will present a password prompt to the user and will then issue the request including the correct Authorization header.

The general message flow above is the same for most (if not all) authentication schemes. The actual information in the headers and the way it is encoded does change!

Caution

The “Basic” authentication scheme used in the diagram above sends the credentials encoded but not encrypted. This would be completely insecure unless the exchange was over a secure connection (HTTPS/TLS).