Authorization
eZintegrations platform supports all sort of Authorization for any standard APIs like REST API, SOAP API, gRPC or GraphQL.
- API Key
- Basic Authentication
- OAuth1.0
- OAuth2.0
- AWS Signature
- NTLM Authentication
- Custom Algorithm Signature
- Any other custom architecture based Authorization
API Key
The API provider generates a unique API key for each client or application that needs access to their API. This key is often associated with specific usage limits or permissions.
Clients must include their API key in the headers or query parameters of their API requests. This key is used to identify the client making the request.
API Key is key-value pair based authorization where the key is Authorization
and the value which is one time string generated from Application while enabling the API for defined set of action with roles and privileges.
There are various application whose API Key are static and its a one time activity to enable those keys, keep them in secret mode and use them for API Authorization
In eZntegrations API Data Source user can select Type as No Auth
under Authorization
and under Headers
call the key as Authorization
and the value as you get from the application
And under Headers add the key-value pair
Basic Authentication
Basic Authentication is a simple method of authenticating access to an API (Application Programming Interface) by sending a username and password with each HTTP request.
In eZintegrations for Source, Operations and Target APIs user can select Type as Basic Auth
under Authorization
Tab
OAuth 1.0
OAuth 1.0: OAuth 1.0 is an open standard protocol that allows third-party applications to access a user's resources (e.g., data) on a server without exposing the user's credentials. It relies on cryptographic signatures and token-based authentication for secure API access.
Here are some key components and steps in the OAuth 1.0 process:
-
Consumer: The consumer is the third-party application or service that wants to access a user's data on a resource server.
-
Service Provider (Provider): The service provider is the entity that hosts the user's resources and manages access to them. It includes popular platforms like Twitter and Flickr.
-
User: The user is the resource owner who has data on the service provider's platform.
-
Token: OAuth 1.0 uses temporary tokens (OAuth token) to grant access to resources. These tokens are issued by the service provider.
-
Signature: OAuth 1.0 requires the use of cryptographic signatures to ensure the integrity and authenticity of API requests.
Since OAuth 1.0 is versatile and hard to predict, eZintegrations provides flexibility to write Python code under Pre-request Script
to achieve the token or signature for Authorization requirement. If user is not aware as how to use the OAuth 1.0, plenty of examples available under section Pre-Request Script
OAuth 2.0
OAuth 2.0: OAuth 2.0 is an authorization framework that enables third-party applications to access a user's data or perform actions on a user's behalf through a secure and standardized process. It defines various authorization grant types and flows for different use cases.
Key components and steps in the OAuth 2.0 process:
-
Resource Owner: The resource owner is the user who has control over their resources and data.
-
Client: The client is the third-party application or service that wants to access the user's resources on a resource server.
-
Resource Server: The resource server hosts the user's data and resources, which the client wants to access.
-
Authorization Server: The authorization server is responsible for authenticating the user and issuing access tokens to the client after the user grants consent.
-
Access Token: OAuth 2.0 uses access tokens, which are short-lived credentials that the client presents to the resource server to access protected resources. They can also include scopes that define the level of access the client has.
In eZintegrations for Source, Operations and Target API user can select the Type
as OAuth 2.0
Refresh Token URL :
The "Refresh Token URL" is the specific endpoint on the authorization server where the client sends a request to obtain a new access token using a refresh token. This URL is provided by the authorization server as part of the OAuth 2.0 protocol.
Example : https://www.googleapis.com/oauth2/v4/token
Refresh Token Method :
In OAuth 2.0, when a client application needs to obtain a new access token using a refresh token, it typically makes a POST request to a specific endpoint known as the "Token Endpoint" rather than a "Refresh Token URL." The Token Endpoint is where the client exchanges its refresh token for a new access token
HTTP POST Request: The client sends an HTTP POST request to the Token Endpoint of the authorization server. This request includes the following parameters:
-
grant_type
: This parameter should be set to "refresh_token" to indicate that the client is using a refresh token to obtain a new access token. -
refresh_token
: The refresh token issued to the client during the initial authorization process. -
client_id
andclient_secret
(optional): These are the credentials of the client application if it's required by the authorization server. Not all OAuth 2.0 implementations use client credentials in this step.
eZintegrations provides all method available.
Refresh Token Endpoint Header:
Some of the common headers that can be used during the process of getting an access token via a refresh token:
Request Headers
This header is required in cases where the client authentication method involves client credentials.
Content-Type Header
The Content-Type header specifies the format of the data being sent in the request body. For OAuth 2.0, the Content-Type is typically set to "application/x-www-form-urlencoded" for form-encoded data.
{"Content-Type":"application/x-www-form-urlencoded"}
Refresh Token Endpoint Params :
Refresh Token Endpoint Params are the parameters that may needed to extend in Refresh Token URL which may be needed for filtering the request. Below is such example to add in this field
{
"params1":"your_params1",
"params2:"your_params2"
}
Refresh Token Endpoint Body:
In OAuth 2.0, the term "Refresh Token Endpoint Body" typically refers to the parameters that are included in the HTTP request body when a client application requests a new access token using a refresh token. This process is part of the OAuth 2.0 token refresh flow, where the client exchanges a valid refresh token for a fresh access token. The refresh token body contains specific parameters that convey the client's intent and identity to the authorization server.
Here are the key parameters that are commonly included in the refresh token endpoint body:
grant_type
Parameter: This parameter is required in the request body and specifies the grant type being used. In the context of a token refresh request, it should be set to "refresh_token" to indicate that the client is using a refresh token to obtain a new access token.
Example:
"grant_type":"refresh_token"
refresh_token
Parameter: The refresh_token parameter is also required and contains the refresh token issued to the client during the initial authorization process. This refresh token is used as proof that the client has previously been granted access and is eligible for a new access token.
Example:
"refresh_token":"your_refresh_token"
client_id
Parameter (Optional): Some OAuth 2.0 implementations require the inclusion of the client_id parameter in the refresh token request to identify the client making the request. It depends on the authorization server's configuration.
Example:
"client_id":"your_client_id"
client_secret
Parameter (Optional): If the authorization server requires client authentication (using a client secret), the client_secret parameter should be included in the request. Not all OAuth 2.0 implementations use client credentials in the token refresh flow.
Example:
"client_secret":"your_client_secret"
When a client sends a POST request to the token endpoint of the authorization server with the above parameters in the request body, the authorization server processes the request. If the refresh token is valid, and any required client authentication is successful, the authorization server issues a new access token in the response body.
Here is an example of a Refresh Token Endpoint Body
:
{
"grant_type":"refresh_token",
"refresh_token:"your_refresh_token",
"client_id":"your_client_id",
"client_secret":"your_client_secret"
}
Refresh Token Endpoint Body
can be given in JSON
format or in String
Format. Preferred one is in JSON
format
It's important to note that the specific parameters required and the format of the refresh token body may vary depending on the OAuth 2.0 implementation and the authorization server's policies.
When working with OAuth 2.0 and sending data in URL-encoded format, user can provide values in the Refresh Token Endpoint Body
field in the following JSON format :
{
"grant_type":"password",
"client_id":"your_client_id",
"client_secret":"your_client_secret",
"username":"your_username",
"password":"your_password"
}
When dealing with OAuth 2.0 and sending data in URL-encoded format as a string
, you can provide values in the Refresh Token Endpoint Body
field using the following format:
"client_id=your_client_id&client_secret=your_client_secret&grant_type=refresh_token&refresh_token=your_refresh_token"
Note with string
in Refresh Token Endpoint Body
it will not support special characters like %, ^, *
etc.