Free Trial


We appreciate your consideration of our secure identity and authentication solutions. Each approach we offer represents a distinct method of achieving the same goal: verifying a user’s identity and confirming their use of a unique authentication device—while eliminating risk in the process.

To use either of the following authentication methods, the individual must have the AffirmedID Authenticator App installed on their mobile device. Step-by-step installation instructions can be found selecting Get App choice.

Also, for the purpose of these examples, use this Register selection to register an email address as your username to use in the following. It should be the same as assigned when registering the AffirmedID Authenticator app.





OpenID Connect (OIDC)

Our OIDC-based solution offers a modern, lightweight alternative built on OAuth 2.0. Like other implementations, it is developer-friendly, mobile/native-first, and provides robust API authentication—but with critical differences .

Unlike typical client-side approaches, AffirmedID employs a server-side token management design , ensuring tokens are securely stored on the server rather than in the browser. This architecture delivers significantly stronger protection against token theft and session hijacking.





Authentication Diagram
SAML

Our SAML-based Single Sign-On (SSO) implementation enables employees and users to access all of their applications with a single set of credentials, established through one authentication ceremony per session. From that point on, reauthorization and reauthentication occur seamlessly in the background as the user moves between applications.

What sets AffirmedID apart is the critical reauthentication step during each transition. While other solutions stop at reauthorization alone, AffirmedID ensures that identity assurance is continuously validated. The importance of this distinction is explained further under Continuous Authentication.


Authentication Diagram

Authentication using SDK Access

In applications where neither SAML nor OIDC is used, it may be desirable to have secure MFA meeting the AAL3 definition. For this we have an SDK, a library against which developers can connect their applications for authentication.

For authentication, it operates exactly the same as OIDC and SAML. One key difference, however, is that SDK authentication has no default session construct. Don’t be fooled by the Logout option on our demonstration; it’s there as a convenience and not indicative of a formal monitored session.

Using this method but within a session, it is probably wise to add support for OAuth 2. Outside our OIDC environment we provide no OAuth support, but others do.



Authentication Diagram
Continuous Authentication Monitoring (CAM)

Continuous authentication monitoring (CAM) is made up of 3 components: the event source, policy decision point (PDP), and policy enforcement point (PEP).

AffirmedID app events include PIN status, location, proximity, and behaviors. In session, these are uploaded to the cloud, where they are forwarded to the PDP located in the API cloud server service. Analysis performed by PDP produces events that are sent to the PEP in the identity provider service (OIDC or SAML). In parallel, and if enabled, the raw signal inputs sent to PDP are also exported using Syslog to external PDPs.

PEP performs final analysis and exports warning and error messages to the tenant dashboard. For those events configured to do so, the session is terminated by logout.


Authentication Diagram
An error has occurred. This application may no longer respond until reloaded. Reload 🗙