Authentication Actions
An authentication action operates on attributes during an authentication flow. Actions can read attributes like the user's account details or use runtime attributes that an authenticator retrieves from external systems. Actions can manipulte data and make it available during token issuance, to provide runtime context to your APIs and applications.
Getting Started#
To create an authentication action, sign in to the Admin UI and navigate to Profiles → Authentication Service → Authentication Actions. Then select the + New Action option to select from one of the built-in options.

Create an Authentication Action
When getting started, choose a simple option like the Debug Attribute Action .
Add it to an Authenticator
Next, add the action to an authenticator that a client uses.
Run a Code Flow
Next, the client triggers user authentication, most commonly with an OAuth code flow.
The following screenshot shows the username authenticator with a debug action configured. After the user types their username or email, the debug attribute action presents a screen that renders all authentication attributes.

The debug attribute action is useful when developing non-trivial authentication flows. The debug attribute action then renders attributes returned by external systems or attributes set by earlier authenticators and authentication actions.
You add actions to authenticators to run after login or after SSO. Typically there is no need to have the same actions in both the Login and the SSO swim lanes.
Authentication Action Concepts#
The following examples provide a rough categorization of the most commonly used authentication actions:
Logic Actions
The script transformer action is one of the most powerful authentication actions. It enables you to run any custom logic to manipulate and transform attributes. Results feed into other actions or token issuance.
Authentication Triggering Actions
The MFA condition enables you to customize authentication per user type, typically based on an attribute that a logic action sets. The Opt-in MFA action can enable users to control their second authentication factor during multi-factor authentication.
Form Actions
The attribute prompt and signup actions present forms with custom elements. You provide input elements in the visual designer and assign them types like text fields and check boxes. You can use regular expressions to validate input or JavaScript validation procedures for more complex validation rules.
Data Actions
Data actions integrate with data sources to collect attributes. The data source transformer action can read attributes from a source like the user’s account. The update account action can save any data collected by forms or set by logic back to the user’s account.
Utility Actions
There are a number of utility actions that perform small tasks, which you can use in a drag and drop manner from the authentication workflow designer. Examples are the sequence, switch, selector and bundle actions. These utilities keep actions understandable or can make reuse easier.
Time or Location Actions
For some use cases, such as for employees, you can restrict logins to particular times and places. Date / time actions allow authentication to succeed at only specific times, such as during business hours. Similarly, geolocation actions can deny logins from untrusted places, such as locations reported to be sources of cyber-attacks.
Account Linking Actions
When a user has an existing account and then authenticates with an external identity provider (IDP), the link account action creates a linking database record with the external IDP’s subject value. On all subsequent logins, the resolve account action enables the user to quickly sign in with the external IDP.
The Authentication Workflow Designer#
Authentication action present a tool for orchestrating what happens after authentication but before the session is committed. You add actions to authenticators and the actions expand into an authentication workflow designer window, which looks similar to a flow chart.

When actions execute, the user has authenticated, but the system hasn’t yet produced an authenticated session that can be used later for single sign-on. In the authentication workflow designer there are three main types of attributes that actions execute upon, and for most actions you should use action attributes:
- Action attributes. These values are used by a set of actions and then discarded once user authentication completes.
- Context attributes. Use context attributes to flow authentication attribute values into token issuance.
- Subject attributes. Use subject attributes to set values to save to the authenticated session, like the subject value.
Extensibility Points#
Authentication actions are implemented with a plugin system that enables each action to use shared frontend and backend behaviors. The Authentication Action Base Configuration page provides an overview and links to further information.
Authentications actions can integrate with other key interfaces to enable you to compose user authentication steps in powerful ways. For many use cases you can use the authentication workflow designer to compose actions, with minimal code. When required, you can take full control over data, logic and presentation via the plugin system.
Data Sources
You can read custom attributes from any data source that uses an attributes query, which is commonly a SQL statement. The results become authentication attributes that you can use during authentication logic.
Web Services
The script transformer action can call external web services such as your own APIs or the Entra ID Graph endpoint. This gives you the ability to import additional authentication attributes or make external updates.
Custom JavaScript Logic
Once you have any required authentication attributes, use custom JavaScript in one or more script transformer actions to use or transform attributes. The logic could use the user’s type or stored preferences to control the main authenticator or second factor.
Custom Authentication Actions
You can develop a custom action that uses frontend components and backend HTTP endpoints. For example, you could use a plugin to develop bespoke self-signup forms to implement a complex Know Your Customer (KYC) flow.
Representations#
Form-based authentication actions can use multiple frontend representations. By default, actions use HTML forms and render in the browser. Applications can use the Hypermedia Authentication API (HAAPI) to implement API-driven login flows. Authenticators then return JSON form representations rather than HTML form representations. HAAPI avoids redirecting users during logins and is often used to enable a Pure Native Mobile Login User Experience.
Learn by Use Case#
The Curity website provides many learning resources where you can learn more about authentication action use cases:
Curity Online Training#
The best way to learn about authentication actions is to implement flows that use them. The Administrator Training Courses walk you through a number of authentication actions to explain how to implement various mainstream authentication journeys.