HTTP Headers
Authorization
HTTP Header
The HTTP Authorization request header is used to send credentials that authenticate a user agent with a server, granting access to protected resources.
The Authorization header is typically sent after the user agent initially tries to access a protected resource without credentials.
The server responds with a 401 Unauthorized message, which includes at least one WWW-Authenticate header.
This header specifies the authentication schemes available for accessing the resource and provides any additional information required by the client to utilize them.
The client should choose the most secure authentication scheme it supports from the options provided, prompt the user for their credentials, and then resend the request with the encoded credentials in the Authorization header.
This header is omitted during cross-origin redirects.
Syntax
Authorization: <auth-scheme> <authorization-parameters>
/* Basic authentication */
Authorization: Basic <credentials>
/* Digest authentication */
Authorization: Digest username=<username>,
realm=<realm>,
uri=<url>,
algorithm=<algorithm>,
nonce=<nonce>,
nc=<nc>,
cnonce=<cnonce>,
qop=<qop>,
response=<response>,
opaque=<opaque>
Directives
- <auth-scheme>
The Authentication scheme defines how credentials are encoded when sent over a network. Common types include (case-insensitive): Basic,
Digest,Negotiate, andAWS4-HMAC-SHA256.
Beyond the <auth-scheme>, other directives are usually specific to each authentication scheme. It is recommended to consult the relevant specifications for these, with key parameters for some schemes listed below.
Basic authentication
<credentials>
The credentials are encoded based on a specific scheme chosen for authentication.
Digest authentication
<response>
A string consisting of hexadecimal digits that demonstrates the user possesses the correct password.
The algorithm encodes various elements such as username, password, realm, client nonce, quality of protection (qop), nonce count, and others.
This process is described in detail within the relevant specifications.
username
A quoted string containing the user’s name for the specified realm, which can be in plain text or a hexadecimal hash.
If the username includes characters not allowed in the field, useusername*instead, formatted according to RFC5987.
username*
The user’s name encoded with an extended notation as specified in RFC5987.
Use this only when the username cannot be encoded in theusernamefield, especially ifuserhashis set to “false”.
uri
The effective request URI, which indicates the resource being accessed.
Refer to the specifications for further details.
realm
The realm of the requested resource, usually matching the value in the
WWW-Authenticateheader sent by the server.
opaque
This corresponds to the opaque value provided by the server in the
WWW-Authenticateheader, used for maintaining state.
algorithm
The algorithm used to calculate the digest, which must be supported and specified in the
WWW-Authenticateheader.
qop
A token indicating the level of message protection, such as
"auth"for authentication or"auth-int"for authentication with integrity protection.
Must match a value specified in the server’sWWW-Authenticateheader."auth": Authentication
"auth-int": Authentication with integrity protection
cnonce
An ASCII-only string provided by the client, quoted.
This nonce is used in mutual authentication, message integrity, and to prevent certain cryptographic attacks.
See the specifications for detailed information.
nc
Nonce count, indicating the number of requests sent with the same
cnonce. It is a hexadecimal counter and helps the server detect replay attacks.
userhashOptional
Set to
"true"if the username is hashed; defaults to"false".
Example
Basic authentication
For Basic authentication, credentials are formed by concatenating the username and password with a colon (e.g., aladdin:opensesame), then encoding this string using Base64 (e.g., YWxhZGRpbjpvcGVuc2VzYW1l).
http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1lWarning: Base64 encoding is easily reversible, which means the original username and password can be recovered. Therefore, Basic authentication alone does not provide security through encryption.
Always use HTTPS to secure data during transmission, especially when using Basic authentication.
For additional examples on configuring HTTP basic authentication, refer to server setup guides for HTTP authentication on platforms such as Apache or Nginx.
How to Modify Header using Requestly
Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Authorization header. This is especially useful for testing authentication flows or debugging API access issues during development. Steps to Modify the Authorization Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Authorization.
- In the “Header Value” field, enter your token or credentials (e.g., Bearer your-token-here).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
- Save the rule.
Once set up, Requestly will inject the Authorization header into all matching requests, enabling you to test authentication or simulate different users without changing your application code. Sometimes, you may want to modify the Authorization header to test how your app handles different login states or API key accesses. It’s a simple way to debug security issues or simulate multiple user roles quickly.
Table of Contents
- No headings found.
