Authentication Flow API
API reference detailing all endpoints, inputs and results supported by the Authentication Flow API.
Last updated
API reference detailing all endpoints, inputs and results supported by the Authentication Flow API.
Last updated
Welcome to the API reference for the Authentication Flow API. On this page, you'll find a complete list of all the actions supported by the API.
For an overview of what the Authentication Flow API is, see this post .
This section of the API reference documentation covers the following:
Endpoints
How to make your first HTTP request to the authentication flow endpoint.
Authentication Flow Types
How state token works
API inputs and responses
The Authentication Flow API has two endpoints. The endpoints are:
/api/v1/authentication_flows
: This endpoint can be used to initialize a new authentication flow. Or to perform a flow that requires just one step/HTTP request to finish.
/api/v1/authentication_flows/states/input
: This endpoint requires a state_token
parameter in the request body. The value for the state_token
parameter must be a valid state token gotten from a previous step/request to the Authentication Flow API.
Both endpoints only support requests made over HTTPS using the POST method. Requests made over plain HTTP will be refused. The supported content type for the request is application/json
.
The first step for using the Authentication Flow API is to create a new authentication flow.
An authentication flow basically starts with an HTTP request to the /api/v1/authentication_flows
endpoint. The endpoint will respond with data such as a state_token
and an action
object that will determine what the next step (request) will be executed. The action
object returns different values for its own type
property (action.type) which include: identify
, authenticate
, verify
, finish_redirect_url
, etc.
At the minimum, this step involves sending an HTTP request to the Authentication Flow API endpoint with the type
and name
parameters in the request body.
HTTP Request:
Here's a sample of what the HTTP request to create a new flow of "type"
: "login"
will look like this:
The above code block shows how the structure of a typical HTTP request to the Authentication Flow API should be configured. Here's a breakdown of all the different parts of the request:
The API expects a POST request sent over HTTPS.
The endpoint to make an HTTP request to is /api/v1/authentication_flows. An example of the full endpoint is https://{your-project.authgear.cloud}/api/v1/authentication_flows
. Replace {your-project.authgear.cloud}
with the valid domain name for your Authgear project.
Always set the request content type as Content-Type: application/json as the API only accepts inputs as JSON.
The JSON object containing values for type and name can then be passed in the request body.
HTTP Request for a Single-Step Authentication Flow:
The following section shows an example request for a single-step authentication flow that uses the phone number + password login method.
The Authentication Flow API supports the multiple login methods that you can enable for your project on the Authgear Portal. Hence, to use a single-step authentication flow like in the example below, ensure that the phone number + password login method is enabled and the user has it enabled for their account.
Example:
The following are examples of how to make an HTTP request to the API to start a login flow from your code:
Note: In order to get the finish_redirect_url
at the end of your authentication flow, you must include the value of the entire URL Query generated by Authgear in your initial HTTP request for your authentication flow. The URL Query is a set of parameters that the Authgear authorization server adds to your Custom UI URI when redirecting users to your custom authentication UI.
You can specify the kind of authentication flow you wish to initialize using the type
parameter in your HTTP request body.
At the moment, the API supports these three values in the type parameter:
signup
: The flow to sign up as a new user.
login
: The flow to sign in as a new user.
signup_login
: This flow will either become a signup or login depending on the input. If the end-user enters an existing login ID, then the flow will become login, otherwise, it is signup.
account_recovery
: You can use this type to create a flow like account recovery or password reset.
The state token can help you track the state of your authentication flow. Every successful response from the API endpoint includes a stake token. The following is an example of a state token in an HTTP response:
You can include this state token in the body of your next HTTP request to continue the flow. Below is an example of a request that uses the state token in the above example to continue to the next step of the login
type flow.
HTTP Request:
Example:
The Authentication Flow API supports inputs passed in the HTTP requests body as JSON. Some special fields such as type
, name
and state_token
can be passed directly as parameters in the request body. However, other values like user inputs must be passed using the input
or batch_input
field.
In order to pass inputs that modify the state of the authentication flow, you must make your HTTP requests to the /api/v1/authentication_flows/states/input
endpoint instead of /api/v1/authentication_flows
.
We've provided the structure for a request with inputs below:
HTTP Request:
From the above schema, notice how the state_token parameter is a direct parameter in the request body. User inputs such as email address and password on the other hand are within the batch_input parameter as elements in an array.
The keys for sending email and password are special words specified by Authgear. Usually, you'll find these keys in the response from the previous step of your authentication flow.
The structure of the HTTP response from the Authentication Flow API tries to be as consistent as possible all the time. In other words, the structure of responses is always the same. This response is in JSON format.
Successful responses return a 200
HTTP status code and the response body look like this:
state_token
: The token that refers to this particular state of an authentication flow.
type
: The type of the authentication flow. Possible values aresignup
, login
and signup_login
.
name
: The name of the authentication flow.
action
: An object containing information about the next step based on the current request. For example, if we send only identification
information (for instance email) in the current request, action.type
will be authenticate
and action.data
will contain information about the enabled authentication methods.
action.data.device_token_enabled
: When the value of this field is true
, you can send request_device_token: true
in your next input to skip 2FA. The action just described is equivalent to checking "Skip 2FA next time on this device" box in AuthUI. Authgear stores device token in the browser cookies to allow skipping of 2FA in the future.
The Authentication Flow API returns an HTTP status code within the 400 range when a request is not successful. The following is an example of the body of an error response:
reason
: You can use this string to distinguish between different errors. Do NOT use message
as it could change over time.
info
: An object containing extra information about the error. It can be absent (i.e. not null
, but absent).
Here, we'll provide details about all the supported action types (action.type
) for signup flow and login flow.
This is usually contained in the response from the first step of an authentication flow of type: signup
.
HTTP Request:
When you make the above HTTP request to create a signup flow, you get a response that looks like this:
You can select one of the options and then include it in the next step (request) of your authentication flow like this:
This action requires the UI to create a new authenticator. For example, you can use the create_authenticator
action to set a new password for a new user during account creation (signup).
Response:
To set the primary password for the new user, send the following input in your next request:
Sending the above input will complete the signup flow for signup using the primary_password authentication. Hence, the value action.type
in response to the next request will be "finished".
If you create an authentication flow of type: login
without defining any of input
or batch_input
, the response to your HTTP request will include action.type:identify
.
Below is the structure of a simple HTTP request for creating a login flow.
HTTP Request:
The response for the above HTTP request will look like this:
You can use one of the options ( "identification": "email") to continue the login flow by passing it in your next request using the input parameter like this:
actiontype.type:authenticate
is returned in the response for the step that passes an identification option in its request body. The response that includes this action looks like the following:
You can pass the authenticator value (user's primary password) in your next request using the input parameter like this:
For a simple login with a primary password only, sending the above request will return action.type: finished
which means the authentication flow is completed.
The response that includes this action may look like this:
To send the OTP for the verification process, use the state token returned in the response to send the following input in your next request:
The response to the above request should look like this:
If otp_form
is code
, an OTP will be sent to the end user at masked_claim_value
.
To resend OTP, send another request in a new step with the following input:
Next, submit the OTP sent to the user using the following input in your request:
Or, you'll get the following response if the OTP form is a link:
if otp_form
is link
, can_check
initially is false
and websocket_url
will be present in data
. You can connect to a WebSocket with this URL to listen for the event of the link being approved.
The verification link will be sent to the end user via the email in masked_claim_value
. When the user clicks on the link, the default approval page will open.
The retrieved state should have can_check=true
.
Now you can pass this input to check if the link has been approved:
The response that contains this action looks like this:
To submit a new password send the following input in your request:
The following is a sample of a response that contains this action:
To complete the password reset process pass the following input:
This is a special kind of response that is returned at the end of the authentication flow.
Example:
The value for action.type
for the finish response is "finished" as this is the end of the authentication flow.
In this section, we'll cover all the supported identification options and how to pass them as input.
Presence in response body:
Usage in input:
Presence in response body:
Usage in input
Note: The phone number MUST BE in E.164 format without any separators or spaces.
Presence in response body:
Usage in input:
Presence in response:
provider_type
: The expected value here is a keyword for a specific OAuth provider. Possible values are:
google
facebook
github
linkedin
azureadv2
azureadb2c
adfs
apple
wechat
alias
: The identifier of the OAuth provider. You pass this in the input.
Usage in input:
The response to an Authentication Flow API request with the above input should look like this:
In order to continue with the flow, redirect the user to the OAuth provider's authorization page using the link in action.data.oauth_authorization_url
.
Once the user successfully grants your application authorization on the OAuth provider's site, they will get an authorization code. This code is usually returned by the provider in your OAuth redirect URL as a code
query parameter.
Next, send the authorization code in your next HTTP request to the Authentication Flow API in your input like this:
In some cases, the user may be unable to grant authorization successfully. In such situations, you can continue your authentication flow more gracefully by sending the following error-handling input in your next HTTP request instead:
error_description
and error_uri
are optional.
Here we'll cover all the supported authentication methods (authenticators) and how to pass them as input.
Presence in response:
The value of password_policy
is an object that contains all the requirements for a password. The following are all the possible attributes for the password_policy
object:
Usage in input (for login flow):
Usage in input (for signup flow)
Presence in response (for login flow):
In the above response, otp_form
tells you what kind of OTP will be sent. masked_display_name
tells you what email address the OTP will be sent to. channels
tells you the available channels you must choose from.
Presence in response (signup flow):
Usage in input (for login flow):
To reference this authentication, use its index in options
array. The next step for using primary_oob_otp_email in your signup flow will be verifying the OTP sent to the user's email.
You can verify the OTP by sending the OTP in the input of the next request for your login flow like this:
Usage in input (for signup flow)
Presence in response (for login flow):
otp_form
tells you what kind of OTP will be sent. masked_display_name
tells you what phone number the OTP will be sent to. channels
tells you the available channels you must choose from.
Presence in response (for signup flow):
Usage in input (for login flow):
To reference this authentication, use its index in options
array.
Usage in input(for signup flow):
Presence in response:
Usage in input (for login flow):
Usage in input (for signup flow):
Presence in response:
Usage in input:
Note: target
can be different (and is usually different) from the email address the end-user uses to sign in.
Presence in response:
Usage in input:
Note: target
MUST BE in E.164 format without any separators or spaces. It can be different (and is usually different) from the phone number the end-user uses to sign in.
Presence in response:
Usage in input (for login flow)
Usage in input (for signup flow):
Sending "authentication": "secondary_totp"
in the input for your signup flow request will return a response that looks like this:
You can encode the value of action.data.otpauth_uri
into a QR code that users can scan in an Authenticator app. Or display the value of action.data.secret
so they can manually enter the secret in the Authenticator app.
To complete the TOTP authentication flow, send the code generated from the Authenticator app in your next request like this:
You can use the state token to retrieve more details about an existing state. You can do so by making the following HTTP request:
Typically you do not need this because the state is returned after creation or after input was passed.
In this section, we'll cover how the Authentication Flow API handles different kinds of errors.
The Authentication Flow API returns an HTTP status code within the 400 range when a request is not successful. Or, an error with HTTP status code when there's an internal error in the server.
Some fields may be absent in the error response from the Authentication Flow API depending on the type of error that occurred. Hence, we recommend doing checks for such fields in your code before using them in your application logic.
The main HTTP response from the Authentication Flow API may include an error
field when an error
occurs in the authentication flow. The value of the error
field is the error object. The error
object includes the following fields:
name
: this is a short tag that qualifies a set of related errors.
reason
: The value of the reason field can be used to distinguish between different types of errors. It is more specific than the name
field, and more reliable for usage in application logic than the message
field as the value of the message
field can change.
message
: the value of the message
field is a string that contains more descriptive information about the error that has occurred.
code
: This is the HTTP status code associated with an error. Examples include 500, 400, 401, and 404.
info
: The info field may be absent in an error response. When it is present, the value is an object that contains more detailed information about the error that has occurred. Below are more details about some of the data in the info
field.
The error.info
object may include these fields:
FlowType
: This field tells the type of authentication flow for which the error has occurred. For example, login
and signup
flows.
causes
: This is an array with more details about all the possible sources of the current error and hints on how to resolve the error.
cause
: The value of cause is an object with simple details about why the current error occurred.
To further understand the structure of the error response from the Authentication Flow API, lets consider some examples of common errors. We'll categorize the errors using the error.reason
The value of error.reason
can be ValidationFailed
when there's a missing required field. In the example below, the error occurred because the request to Authentication Flow API's /api/v1/authentication_flows/states/input
endpoint is missing a required input
or batch_input
field.
Another cause for a ValidationFailed
error is an invalid format in the value of a required field or an invalid constant in a required field.
An example of an invalid constant is setting the value of identification
to anything outside the allowed values (email
, phone
, oauth
, username
). Also, using a constant for any feature that is not supported by your current login methods may throw the same error. You can always find more specific details about the cause of the error in the error.info
object.
The following example shows a ValidationFailed
error for when a user enters a string that's not the correct format for an email address:
An InvariantViolated
error may occur when the input for a signup flow contains an identity (email, phone, or username) that already exists for another user. You can find more specific details about the cause of the InvariantViolated
error in the error.info
object.
The following example shows an error response for a signup flow that attempts to register a new user with an email that already exists for another user:
When the value for a new password does not meet the minimum password requirement for your Authgear project, the Authentication Flow API will return an error with PasswordPolicyViolated
. More details about how the password in the request fails to meet the requirement will be in the error.info
object.
In the following example, the password in the request fails to meet the minimum length of 8 characters:
The value of error.reason
can be AuthenticationFlowNotFound
when the state_token
in the request is invalid or expired. This type of error does not include the info
field.
The Authentication Flow API will return an InvalidCredentials
error when an authentication fails because the input value for an authenticator is invalid ( e.g. a wrong password is entered for an existing user).
More details about the authenticator type can be found in the error.info
object as shown below:
A UserNotFound
error will occur when the input value for user identity (email, phone, username) does not exist in an Authgear project. In other words, no user was found for the email, phone number, or username.
More details about the error will be in the error.info object.
This is a rare error that may occur due to improper inputs such as poorly formatted JSON (e.g. including a trailing comma in JSON).
The type
parameter defines the while the name
parameter can be set to "default".
The action.data.options
object in the response contains an array with . For example, the presence of { "identification": "email" }
means you can continue the above signup flow using an email address to identify the user.
From the above response action.data.options
shows that we can use the primary_password
authentication method. Learn more about all the authenticators supported by Authgear, in the .
action.data.options
contains a list of all .
The action.data.options
object for the above response contains all the supported authenticators. As you can see, for the above example, only the primary_password
authenticator is supported. To learn more about all the authenticators supported by Authgear, check out the .
A WebSocket message of a JSON object {"type": "refresh"}
is sent once the user approves the link. Upon receiving the message, you can .
action.data.finish_redirect_uri
contains a URL that can be used to hand the authentication process back to Authgear so that it can redirect the user back to the client application. You can hand the authentication process back to Authgear by simply initiating a redirect to the URL in action.data.finish_redirect_uri
from your custom authentication UI. See our example of .
The rest of the steps for implementing primary_oob_otp_sms
in a login flow is similar to . The major difference is the change in the channel
from email
to sms
.