Authentication Concepts

On this page

The Authentication Service focuses on identifying users and clients to prove who they are. The correct way to implement different forms of authentication is to let the Identity Server manage it for you.


In your apps, you will write standard code to implement an OAuth 'flow'. The actual sign-in method can then be configured to work in many ways without further code changes. Here is a small selection of example authenticators:

Username PasswordOften used when companies need a default password based login option that works for anyone.
GoogleThis type of option allows a user to sign in with a familiar password.
Azure ADCommonly used by companies to force use of corporate credentials, so that access is limited to employees.
WebAuthnIntegration with devices provides friendly login with strong cryptographic credentials based on public and private keys.
BankIDAn advanced authenticator that signs users in via a separate third party financial grade login app.

Authentication Selection

If required, clients can gain closer control over how to authenticate based on runtime conditions, using the standard acr_values query parameter. Alternatively, you may prefer to allow the user to choose an authenticator from a list.

Multi-Factor Authentication (MFA)

Multiple factors can be chained together to form a workflow that provides stronger security guarantees. In some sectors, MFA is mandatory in order to meet Strong Customer Authentication (SCA) regulatory requirements. MFA must include at least two of the following aspects:

  • Something the user knows, such as a password
  • Something the user owns, such as a keyfob
  • Something the user is, such as a biometric input

API Driven Authentication

Authentication is handled as a workflow, where browsers are instructed what to do next by server HTML responses. We also provide a Hypermedia Authentication API to remove dependencies on HTML, with benefits in these areas:

  • Improved user experience, with no need to leave the app to sign in
  • Stronger security, by avoiding the browser in many cases, and by proving the client's identity

Authentication Actions

An Authentication action can be thought of as aRuntime Script to dynamically control authentication behavior, as in the below examples:

  • Use runtime conditions, such as the user's location, to determine which authenticators to use
  • Process authenticator results to ensure that a consistent subject claim is included in tokens

Login User Experience

We recognize that Login User Experience is important. Thus, Curity allows customization via either of the following methods:

  • HTML, CSS and Javascript customization
  • Custom rendering of Hypermedia API responses

HTML customization can be done separately per OAuth Client if required, and custom resources are stored in a folder structure that avoids duplication and deals elegantly with Identity Server upgrades.

Protocol Support

Curity is a certified provider of multiple security standards, as listed on our Conformance Page. This includes many standards from the Financial Grade API (FAPI) Working Group. We are continually growing our support, to add newer standards such as CIBA and DPoP.

Single Sign-On

The Identity Server implements Single Sign-On and full Session Management according to OpenID Connect standards, including all logout variations. SSO cookies can also be restricted to the current browser session if needed to force re-authentication when the browser is restarted.


When required, the system has strong support for capturing user consent so that end-users are in control of granting access to Personally Identifiable Information (PII) and other data. Consentors can be used to customize this process to handle advanced use cases, such as capturing consent to runtime payment details.

User Self Service

When needed, the system supports the following Self Service operations so that there is no need for manual administrator actions to manage users:

  • User self sign up
  • Email and SMS account verification
  • Account recovery to handle forgotten passwords
  • Registering mobile devices against users

Dynamic Client Registration

In some dynamic business scenarios, partners need to register as OAuth Clients at runtime, to enable zero delay integration. To enable this we support the Dynamic Client Registration (DCR) standard.

Custom Authentication

Standard interfaces for authenticators, actions, and other authentication concepts are published in our SDK, enabling custom solutions to be easily developed. There are many examples in our GitHub Repositories.


Over time, companies will likely want to offer their users multiple authentication behaviors, and you need a toolbox to manage these concerns. It is then important that coherent results feed into access tokens used by APIs, as covered in the Token Concepts article.

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial