Login Flow

The login flow seamlessly manages authentication tasks for all types of flows.

Login Flow Settings

Login Types

• JWauth

• Basic auth

• OAuth2

• Permanent Token

• Custom Header

• Nebim

JWT auth

• URL: This is the endpoint URL where the login request will be sent to authenticate the user and obtain a JWT token. It's typically an API endpoint provided by the authentication service. Ex: “https://example.com/api/v1/auth/login”.

• Custom Headers for Login Request: These are additional headers that can be included in the login request. They might include things like API keys, user agents, or other metadata required by the authentication service. Ex: {"x-csrf-token":"login"}

• Extra Body: This field allows you to include any additional parameters or data in the body of the login request. This could include things like client IDs, secrets, or other authentication-related information.

• Username: This is the username or identifier used to authenticate the user. Ex: “username”.

• Password: This is the password associated with the provided username. Ex: “passw”.

• HTTP header key: This is the key used in the HTTP header of subsequent requests to include the JWT token for authentication. Ex: “Authorization”.

• JSONPath for returned token path: This field specifies the path within the response body where the JWT token is located. JSONPath is a query language for JSON that allows you to specify patterns for extracting data from JSON documents. Examples:

Authentication response:
{"key": "ANEXAMPLEAUTHKEY", "expires_at": "xyz"}
JsonPath value: 
["key"]

Authentication response:
{
  "result": {
	"key": "ANEXAMPLEAUTHKEY",
	"expires_at": "xyz"
  }
}
JsonPath value: 
["result", "key"]

Authentication response:
{
  "results_list": [
	{
  	"key": "ANEXAMPLEAUTHKEY",
  	"expires_at": "xyz"
	}
  ]
}
JsonPath value: 
["results_list", 0, "key"]

• Token prefix: This is an optional prefix that can be added to the JWT token after it's extracted from the response. Ex: “Bearer”.

Basic Authentication

• Username: This is the username or identifier used to authenticate the user. Ex: “username”.

• Password: This is the password associated with the provided username. Ex: “passw”.

• Token prefix: This is an optional prefix that can be added to the token after it's extracted from the response. Ex: “Token”.

Oauth2

• Grant Type:

  • Authorization code

  • Client credentials

  • Password

• Send payload with form data: When this setting is true, the payload, or the data being transmitted, is sent as form data.

• Url: This is the endpoint URL where the login request will be sent to authenticate the user

• Client ID: Client Id information

• Client Secret: Client Secret Information

• Custom Headers for Login Request: These are additional headers that can be included in the login request. They might include things like API keys, user agents, or other metadata required by the authentication service. Ex: {"x-csrf-token":"login"}

• Extra Body: Extra body to send with request. Ex: {"test_body": "true"}

• Username: This is the username or identifier used to authenticate the user. Ex: “username”.

• Password: This is the password associated with the provided username. Ex: “passw”.

• Token Type key: This is the key to find token type in response.

• Scope Key: This is the key of Scope.

• Expires in key: This is the key of expires date information

• Refresh token key: This is the key of refresh token

• Access token key: This is the key of access token

• Scope: Value of Scope information

• State: Value of State information

Permanent Token

• Token Prefix: This is a prefix that can be added to the permanent token. Ex: “Bearer”.

• Permanent Token: The token itself. Ex: “testToken1234”

Nebim

• Method: Method to use for login requests. Ex: “Get” or “Post”.

• Url: This is the endpoint URL where the login request will be sent to authenticate the user

• Custom Headers for Login Request: These are additional headers that can be included in the login request. They might include things like API keys, user agents, or other metadata required by the authentication service. Ex: {"x-csrf-token":"login"}

• Username: This is the username or identifier used to authenticate the user. Ex: “username”.

• Password: This is the password associated with the provided username. Ex: “passw”.

• JSONPath for returned token path: This field specifies the path within the response body where the JWT token is located. JSONPath is a query language for JSON that allows you to specify patterns for extracting data from JSON documents. Ex: ["key"]

• Model Type: Nebim model type

• Database Name: Nebim Database name

• User group code: Nebim user group code

Custom Header

• Send payload with form data: When this setting is true, the payload, or the data being transmitted, is sent as form data.

• Method: Method to use for login requests. Ex: “Get” or “Post”.

• Url: This is the endpoint URL where the login request will be sent to authenticate the user

• Custom Headers for Login Request: These are additional headers that can be included in the login request. They might include things like API keys, user agents, or other metadata required by the authentication service. Ex: {"x-csrf-token":"login"}

• Header fields to get: Fields to read from response headers. Ex: {"header_key_here":"path_to_get_from_headers"}

• Extra Body: Extra body to send with request. Ex: {"test_body": "true"}

• Username: This is the username or identifier used to authenticate the user. Ex: “username”.

• Password: This is the password associated with the provided username. Ex: “passw”.

• HTTP header key: This is the key used in the HTTP header of subsequent requests to include the token for authentication. Ex: “Authorization”.

Omnitron Login

The Omnitron login flow is automatically generated upon project creation, enabling access to Omnitron for reading or writing data. Configuration of the Omnitron login flow is necessary to facilitate this access seamlessly. For each project, only one Omnitron login is required, as each project is associated with a single Omnitron instance for accessing and managing data.

ERP Login

After project creation, an ERP login flow must be manually configured to enable access to ERP systems for data operations. ERP systems may require multiple login flows. Each ERP login flow can serve different types of flows, such as stock flow. However, while multiple stock flows can utilize one ERP login flow, each stock flow can only be associated with a single ERP login flow.