HTTP authentication

Header fields

Header fields that are used for HTTP authentication include

Authorization
Proxy-Authenticate
Proxy-Authorization
WWW-Authenticate

Typical request/repsonse flow

The typical request/response flow between client and server is:

The Client requests resource: GET /path/to/resource HTTP/1.1
The server requests that the client authenticates itself with status code 401: HTTP/1.1 401 Unauthorized and the following header WWW-Authenticate: Basic realm="…"
The client sends the credentials (this step possibly requires the user to provide these): GET /path/to/resource and header Authorization: Basic …
The server answers either with HTTP/1.1. OK or HTTP/1.1 401 Unauthorized.

Authentication schemes

There are two general types of authentication schemes:

Basic authentication
Challenge-response

In basic authentication, the username and password are transmitted more or less in clear text to the server.

With challenge-response, the server sends authentication data to the client. The client uses the user's credentials to transform this authentication data and then sends the transformed data back to the server.

A well known challenge-response scheme is kerberos.

Authentication schemes are maintained at IANA. The list of the schemes is:

Basic	RFC 7617
Bearer	RFC 6750
Digest	RFC 7617
HOBA	RFC 7486 (Section 3)	Used for authentication on a server or a proxy. See also HTTP status 407 («Proxy Authentication Required»)
Mutual	RFC 8120
Negotiate	RFC 4559	This scheme violates HTTP semantics because 1) it is cconnection-oriented and 2) because of the syntax incompability with `WWW-Authenticate` and `Authorization` headers
OAuth	RFC 5849, Section 3.5.1
SCRAM-SHA-1	RFC 7804
SCRAM-SHA-256	RFC 7804
vapid	RFC 8292, Section 3

The 'Basic' Authentication Scheme

The Basic Authentication Scheme protects so called realms. A realm is identified by a string (text) and consists of one or more resources. In order to access the resources that belong to a realm, the user needs to provide a user id/password credential pair.

In order for this authentication scheme to be considered secure, it needs to be combined with an external secure system such as TLS.

A proxy might use a similar challenge using the 407 status code and the Proxy-Authentication header field.

In the command line tool curl, basic authentication is enabled with the --basic option.

Possible exchange of headers between → development/web/HTTP/User-Agent and web server

Initial HTTP request:

GET /some/protected/resource HTTP/1.1
… more headers

The webserver answers with

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic Realm="name of the realm"
… more headers (irrelevant for authenticaton )

<html> …
</html>

The User Agent displays a message box to enter username and password.

A character-string consisting of username and password, separated by a colon (:) is Base 64 encoded and sent with the Authorization header:

GET /some/protected/resource HTTP/1.1
…
Authorization: Basic dXNlcjpwYXNzd29yZA==
…

The webserver decodes the encoded username and password. If correct, it serves the requested resource

OAuth

OAuth 2.0 is specified in RFC 6749

Token exchange is specified in RFC 8693

OAuth is about authorization, not about authentication.

With OAuth 2.0 authorization, it is possible for 3rd party applications to access protected resources without handing out password-based credential to the 3rd party. Instead, the 3rd party obtains an access token that authenticates the 3rd party application when requesting a protected resource.

A refresh token is a token that can be exchanged for an access token.

OAuth relies strongly on HTTP redirection and TLS.

An access token is just string whose format is not further specified. However, a useful common format is provided by JSON Web Token.

An access token is sometimes compared to a car's valet key that can open door and turn on the car but cannot open the trunk.

Access Tokens are specified in RFC 6750.

OAuth defines 4 roles

Resource owner	Grants access to a protected resource. In case of persons, the resource owner is referred to as an end user.
Resource server	The server where the protected resource is hosted. It requires the access token to server the protected resource.
Client	An application that requests a protected resource from the resource server
Authorization server	The server that issues the access tokens.

Four grant types

Authorization code	Used to obtain access tokens and refresh tokens. Optimized for conficential clients.
Implicit	Obtain access tokens - refresh tokens are not supported. Typically implemented in browsers with JavaScript (or another scripting language).
Resource owner password credentials
Client credentials

There's also an extensibility mechanism to define additional grant types.

Two client types

Confidential
Public

OAuth specifically does not specify the interaction between the authorization server and the resource server.

OAuth 2.0 is not backward compatible with OAuth 1.0

OAuth is not related to OATH.