This blog will give an insight of Authorization Request Header. Before we dive into the blog let's get a brief Idea about Authorization Request Headers.
The HTTP Authorization request header contains the credentials to authenticate a user agent with a server.
APIs use authorization to ensure that client requests access data securely. This can involve authenticating the sender of a request and verifying that they have permission to access or manipulate the relevant data. If you're building an API, you can choose from a variety of auth models. If you're integrating a third-party API, the required authorization will be specified by the API provider.
There are many types of Authorization Request Headers. Some of them are mentioned below.
- Basic Auth
- Bearer Token
- API Key
- Digest Auth
- OAuth 2.0
- Hawk Authentication
- AWS Signature
It is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the word Basic, followed by a space and a base64-encoded(non-encrypted) string username: password. For example, to authorize as username / Pa$$w0rd the client would send.
Authorization: Basic AXVubzpwQDU1dzByYM==
Note: Base64 encoding does not mean encryption or hashing! Hence, this method is equivalent to sending the credentials in clear text like ABCXYZ (base64 is a reversible encoding). Prefer to use HTTPS in conjunction with Basic Authentication.
Commonly known as token authentication. It is an HTTP authentication scheme that involves security tokens called bearer tokens. As the name depicts “Bearer Authentication” gives access to the bearer of this token.
The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header while requesting to protected resources:
Authorization: Bearer <token>
Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL). For JWT authentication bearer authentication is recommended
An API key is a token that a client provides when making API calls. With API key auth, you send a key-value pair to the API either in the request headers or query parameters. Some APIs use API keys for authorization.
The key in the query string:
or as a request header:
Digest Authentication communicates credentials in an encrypted form by applying a hash algorithm to the username and the password, the password is converted to response and then it is sent to the server. After that server supplies nonce value, the HTTP method, and the requested URI.
HTTP Digest access authentication is a more complex form of authentication that works as follows:
- Client sends a request to the server
- The server responds with a special code (called a nonce i.e. number used only once), another string representing the realm (a hash) for authentication from the client.
- The client responds with this nonce and an encrypted version of the username, password, and realm (a hash)
- If the Client hash matches the server hash, the server will respond with the requested information. Otherwise, it will pass an error message.
Authorization: Digest username=”admin” Realm=”abcxyz” nonce=”474754847743646”, uri=”/uri” response=”7cffhfr54685gnnfgerg8”
OAuth 1.0 permits client applications to access data provided by a third-party API. For example, as a user of a service you can grant another application access to your data with that service without exposing your login details.
With OAuth 2.0, you first retrieve an access token for the API, then use that token to authenticate future requests. Getting to information via OAuth 2.0 flow varies greatly between API service providers, but typically involves a few requests back and forward between client application, user, and API.
An OAuth 2.0 flow works as follows:
- A client application makes a request for the user to authorize access to their data.
- If the user grants access, the application then requests an access token from the service provider, passing the access grant from the user and authentication details to identify the client.
- The service provider validates these details and returns an access token.
- The client uses the access token to request the user data via the service provider.
Authorization: Bearer hY_9.B5f-4.1BfE //where “hY_9.B5f-4.1BfE” is your OAuth Access Token
Hawk authentication enables you to authorize requests using partial cryptographic verification.
The Hawk Authentication parameters are as follows:
- Hawk Auth ID: Your API authentication ID value.
- Hawk Auth Key: Your API authentication key value.
- Algorithm: The hash algorithm(sha266, sha1) used to create the message authentication code(MAC).
In the request header it is look like as:
Authorization: Hawk id="abcxyz123", ts="1592459563", nonce="gWqbkw", mac="vxBCccCutXGV30gwEDKu1NDXSeqwfq7Z0sg/HP1HjOU="
AWS is the authorization workflow for Amazon Web Services requests. AWS uses a custom HTTP scheme based on a keyed-HMAC (Hash Message Authentication Code) for authentication.
The AWS Authentication parameters are as follows:
- Access Key: API Access key value.
- Secret Key: API Secret key value.
Developers are issued an AWS access key ID and AWS secret access key when they register. For request authentication, the AWSAccessKeyId element identifies the access key ID that was used to compute the signature and, indirectly, the developer making the request.
In the request header it is look like as:
Authorization: AWS4-HMAC-SHA256 Credential=abc/20200618/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=c6c85d0eb7b56076609570f4dbdf730d0a017208d964c615253924149ce65de5
In this tutorial, we have seen how we can use different-2 authorization request header on API calls. I hope this tutorial will help you to understand the Authorization Request Headers.