Customer identity
- Self sign-up with email checks
- Bot protection on sign-up
- Social login
- Passkeys from day one
- Account recovery that resists takeover
- Consent stored with the profile
- Account linking
- Export and deletion requests
Identity and access management
Identity and access management services
Sign-in is the first thing every user touches and the first thing attackers try. Agnotic Technologies builds identity and access management into your own web and mobile applications: sign-up and login, single sign-on, passkeys and MFA, authorization rules and token handling, and the move to a new identity provider when you outgrow the old one.
Customer and workforce sign-inPasskeys and MFAAuthorization modelsProvider migration
Trusted by global innovators
IAM for applications
What are identity and access management services?
Identity and access management services design and build how users prove who they are and what they may do inside your application. Agnotic Technologies sets up sign-up, login, single sign-on, passkeys and MFA, authorization rules and token handling, and connects them to the identity provider that fits your product, budget and assurance level.
This page is about identity inside the products you sell or run: customers signing up, partners and staff signing in, and the rules that decide which records each of them can open.
Corporate directory administration and help desk password resets are not part of this work. A zero trust program across services and networks has its own page, and so do enterprise SSO and SCIM as features a SaaS product adds to win larger customers.
Two audiences
What does customer identity need that workforce sign-in does not?
Most products serve both groups. They can share one identity provider, but the flows and rules differ.
Workforce and partner sign-in
- OpenID Connect or SAML per tenant
- Accounts created on first sign-in
- Groups mapped to app roles
- MFA set by the customer's tenant
- Re-authentication for admin actions
- Access ends when the user leaves
Both audiences
- One user ID that never changes
- Audit events for sign-in and role changes
- Rate limits that slow guessing
- Tenant checks on every request
Assurance levels
Which authenticator fits each assurance level?
NIST SP 800-63B-4 sets three authenticator assurance levels (AAL). We choose the level from the harm a wrong sign-in could cause, then offer only authenticators that meet it.
| Code | Name | Typical use |
|---|---|---|
| AAL1 | One factor: a password of at least 15 characters, a passkey or a one-time code device | Low-risk accounts such as community features or saved preferences. We still offer passkeys so users can skip passwords. |
| AAL2 | Two factors, such as a passkey confirmed with a fingerprint or PIN, or a password plus an authenticator app | Most business and consumer accounts that hold personal, financial or health data. A phishing-resistant option must be offered, and synced passkeys can fill that role. |
| AAL3 | A phishing-resistant authenticator with a key that cannot be exported, such as a hardware security key | Admin consoles, payment approvals and access to large sets of sensitive records. Synced passkeys do not qualify at this level. |
Build or buy
Which identity provider approach fits your product?
Few teams should write their own password storage and token code. The real decision is who runs the identity server, and what it costs to leave it later.
| Factor | Managed identity service | Open source server you host | Custom code on a framework library |
|---|---|---|---|
| Fits when | You want sign-in working quickly and accept the vendor's pricing model and data location | You need control of data location, branding or protocol behaviour and can run a critical service | Sign-in is simple and internal, or identity is the product itself |
| Who patches and scales it | The vendor | Your team, including upgrades and security fixes | Your team, for every line of authentication code |
| Protocols | OpenID Connect, OAuth 2.0 and SAML included | OpenID Connect, OAuth 2.0 and SAML, configured by you | Only what you build or the library supports |
| Passkeys and MFA | Usually included; check which factors each plan covers | Included or added through extensions that you run and test | You build the WebAuthn and MFA flows yourself |
| Cost shape | Per active user or per tenant, rising as you grow | Hosting plus engineering time | Engineering time plus a larger security review |
| Exit path | Confirm before signing that users and hash parameters can be exported | You hold the database | You hold the database |
We name specific products only after the scoping call, once we know your users, regions and assurance level. The migration checklist further down applies whichever way you go.
Authorization
Which authorization model fits your product?
Authentication says who the user is. Authorization decides what they can do, and it is where most access bugs live. We pick the model first, then decide where the policy is evaluated.
01
Role based access control
Example: A clinic scheduling app with admin, clinician and front desk roles inside each tenant
Approach: Roles per tenant, checked in one middleware layer. It works well until roles multiply to cover exceptions.
02
Attribute based access control
Example: Staff may open a case only in their own region and while the case is assigned to their team
Approach: Rules over user, resource and request attributes, evaluated by a policy engine so they live in one place rather than in every endpoint.
03
Relationship based access control
Example: A document product where access follows sharing, folders and team membership
Approach: A graph of who relates to what, checked by a dedicated authorization service. It suits sharing models that roles cannot express.
04
Where the policy lives
Example: Checks scattered across controllers drift apart after a year of new features
Approach: One decision point that every API calls, with tests proving a user in one tenant cannot read another tenant's data.
Tokens and sessions
Where do token and session designs go wrong?
The account takeovers we see in reviews usually come from token handling, not from broken cryptography. RFC 9700 is the checklist we design against.
Challenge
A single-page app keeps access and refresh tokens in browser storage.
Agnotic approach
Authorization code flow with PKCE, and a backend for frontend that holds tokens server-side when the data justifies it.
Challenge
Refresh tokens last for months and are never rotated.
Agnotic approach
Rotate refresh tokens on every use or bind them to the client, and revoke the whole token family when an old one is replayed.
Challenge
A mobile app collects the user's password and posts it to the token endpoint.
Agnotic approach
Move to the authorization code flow in the system browser. The password grant must not be used under the current best practice.
Challenge
One access token carries every permission and every API accepts it.
Agnotic approach
An audience and scopes per API, short token lifetimes, and authorization checked again at each resource.
Challenge
Signing out of one app leaves sessions open in the others.
Agnotic approach
Central session tracking, back-channel logout to each application and an admin action that ends every session for a user.
Challenge
Account recovery by email link is weaker than the login it replaces.
Agnotic approach
Recovery that matches the account's assurance level, with alerts and a waiting period before MFA factors can change.
Migration checklist
How do we move users to a new identity provider without forced resets?
The checklist we follow when a product changes identity provider. Done well, users notice a new login page and nothing else.
Export users and hash parameters
Export profiles, password hashes and the algorithm, salt and cost factor behind each hash. Without them, every user has to reset a password.
Choose bulk import or lazy migration
Import hashes the new provider can verify in one batch, or move each user on their next sign-in by checking the old provider once and storing a new hash.
Keep user IDs stable
Map new identity IDs to your existing user IDs, so orders, records and audit history keep their foreign keys.
Map roles, groups and tenants
Move role grants and tenant membership with the users, and test them against your authorization rules before cutover.
Move or re-enroll MFA factors
Authenticator app secrets can sometimes move. Passkeys belong to the relying party they were registered with, so plan a prompt to register again if that changes.
Cut over login pages and token issuers
Switch the hosted login pages and the token issuer each API trusts, accepting both issuers for a short overlap.
Run old and new in parallel
Watch sign-in success, MFA prompts and support tickets while both providers run, with a switch to roll back.
Remove the old provider
Delete the remaining hashes and secrets, revoke the old signing keys and close the old accounts.
Who asks us for identity and access management work?
Teams usually call when sign-in blocks growth, fails a security review or becomes a large cost line.
Startups adding sign-in for the first time
Identity and access management for startups usually means a managed provider, passkeys from launch and a user model that will survive a later migration.
B2B products selling to larger customers
Per-tenant single sign-on through OpenID Connect or SAML, with roles mapped from each customer's groups.
Consumer apps with high sign-up volume
Bot protection on sign-up, social login and recovery flows that hold up against account takeover.
Teams leaving a homegrown login
Hash export, lazy migration and a token issuer cutover without making every user reset a password.
Regulated products
Assurance levels chosen from the data at stake, with audit events for sign-in and role changes. Patient matching and consent records are a separate problem with their own page.
References
Which standards do we build identity against?
The specifications behind the sign-in, token and authorization choices on this page.
NIST SP 800-63B-4OpenID Connect Core 1.0RFC 9700SAML 2.0W3C WebAuthnOWASP ASVS
Facts and sources
Facts behind identity design
Requirements from NIST, the IETF and the OpenID Foundation that shape the sign-in, token and migration work on this page.
NIST SP 800-63B-4 requires passwords used as a single factor to be at least 15 characters long and bars composition rules and periodic password changes, unless there is evidence of compromise.
Source: NIST SP 800-63B-4 (final, July 2025), Section 3.1.1.2: password verifiersUnder NIST SP 800-63B-4, applications assessed at AAL2 must offer a phishing-resistant authentication option, and AAL3 requires a phishing-resistant authenticator with a non-exportable key, so syncable passkeys are not allowed at AAL3.
Source: NIST SP 800-63B-4: authenticator assurance levelsNIST SP 800-63B-4 requires verifiers to store passwords salted and hashed with a password hashing scheme whose inputs are the password, a salt and a cost factor.
Source: NIST SP 800-63B-4, Section 3.1.1.2RFC 9700, the OAuth 2.0 Security Best Current Practice, requires public clients to use PKCE, requires their refresh tokens to be sender-constrained or rotated, and states that the resource owner password credentials grant must not be used.
Source: RFC 9700 (IETF), Sections 2.1.1, 2.2.2 and 2.4OpenID Connect Core 1.0 is an identity layer on top of OAuth 2.0 that lets a client verify the end user's identity from the authorization server's authentication and obtain basic profile information.
Source: OpenID Connect Core 1.0 (OpenID Foundation)
Scope and cost
What drives the cost of identity and access management?
We do not publish prices. These are the factors we size on the scoping call.
Applications and APIs
Each app that signs users in and each API that checks tokens needs configuration and tests.
User types and tenants
Customers, staff, partners and per-tenant SSO each add flows, rules and test cases.
Assurance level
AAL2 and AAL3 add authenticator choices, re-authentication rules and stricter recovery.
Authorization model
Roles checked in one middleware layer take less work than a policy engine or a relationship graph.
Migration from an existing provider
Hash formats, MFA factors and the length of the overlap period drive the effort.
Provider licence model
Managed services charge by user or tenant. We model that from your own growth plan, not from figures on this page.
Frequently Asked Questions
It depends on the number of applications, the user types and whether users move from an existing provider. We agree the scope and the first release, often sign-in for one application, on the scoping call.
Yes. We connect your apps and APIs to the identity provider you already use, or to a new one, through OpenID Connect, OAuth 2.0 or SAML, and map its users and groups to your own roles.
Rarely. A managed provider or a maintained open source server handles password storage, MFA and protocol details that are easy to get wrong. We keep your user model independent of it so you can move later.
For many users they can, but you still need account recovery and a fallback for devices that cannot use them. NIST SP 800-63B-4 allows syncable passkeys up to AAL2 but not at AAL3, so the assurance level decides where they fit.
Usually. If the old system exports password hashes with their salt and cost factor, the new provider can import them or verify users on their next sign-in. If hashes cannot be exported, lazy migration through the old provider is the fallback.
Yes. A common first release is sign-up, login, passkeys and MFA for one application, with roles checked in one place. Enterprise SSO, a policy engine or a provider migration follow as separate phases.
Engineers may use AI tools to draft code and tests, but every authentication and authorization change is reviewed by a person and covered by tests that try to cross tenant and role boundaries.