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 Password||Often used when companies need a default password based login option that works for anyone.|
|This type of option allows a user to sign in with a familiar password.|
|Azure AD||Commonly used by companies to force use of corporate credentials, so that access is limited to employees.|
|WebAuthn||Integration with devices provides friendly login with strong cryptographic credentials based on public and private keys.|
|BankID||An advanced authenticator that signs users in via a separate third party financial grade login app.|
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
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 claimis included in tokens
Login User Experience
We recognize that Login User Experience is important. Thus, Curity allows customization via either of the following methods:
- 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.
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.
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.
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.