Login and access for apps: authentication and authorization

Picture a company that sells project-tracking software. Most of its 100,000 monthly users sign up on their own, with an email address, a Google account or a passkey. Twenty of its customers are larger companies, and each has asked for the same things in a security questionnaire: let our employees sign in with our company login, add and remove them automatically, and give us a log of who did what. A new PM has just inherited login and permissions, and needs to know fast what to build, buy or run, and how sure anyone can be that a departing employee's access really ends.

Here's how the pieces fit. People and machines (end users, admins, scripts and now AI agents) sign in through an identity provider, which hands the app a token. The identity provider is a hosted service such as Auth0, Microsoft Entra or Clerk, or an open-source server such as Keycloak that you run yourself. The app, whether a SaaS app or a marketplace, trusts that token instead of checking passwords itself. Enterprise customers connect their own directory, usually Okta, Microsoft Entra or Google Workspace, so employees are added and removed automatically. The app then checks every action against its permission rules, in its own code or in a service such as OpenFGA or AWS's Cedar. Broken access checks are the most common serious flaw in web apps, which is why the diagram circles that box.

Attackers go after the weakest link: reused passwords, codes that can be phished and help desks. Infostealer malware lifts saved passwords and session cookies from laptops, phishing kits relay one-time codes in real time, and callers talk support staff into resetting accounts.

The words you'll hear in week one:

• Authentication and authorization: proving who someone is (login), and deciding what they may do once in (permissions). They fail in different places and often have different owners.
• OAuth: the standard that lets one app get limited access to an account elsewhere without the password. The user approves on the account's own server, which gives the app a token with narrow rights ("read your calendar").
• OpenID Connect (OIDC): a thin layer on OAuth that also tells the app who signed in. "Sign in with Google" uses it, and so do newer enterprise connections.
• SAML: the older, XML-based way for a company's identity system to vouch for an employee to an app. Most enterprise single sign-on (SSO) still runs on it.
• SCIM: a standard API a company's directory uses to create, update and deactivate accounts in an app automatically. It handles provisioning and plays no part in sign-in.
• Passkeys: a key pair kept on a phone, laptop or password manager and unlocked with a fingerprint, face or PIN. The app stores only the public half, and the key works only on the real site, so a lookalike page gets nothing it can use.
• JWT (JSON Web Token): a common token format, a signed bundle of facts such as "user 123, organization 9, valid until 10:15". Any server can check it without a database lookup, which also makes it hard to recall before it expires.
• RBAC and ReBAC: role-based access control grants permissions through roles (Admin, Viewer); relationship-based access control derives them from links ("editor of the folder that holds this file"), the model Google described for its own system, Zanzibar, in 2019.

If you only remember a few things:

1. Permission checks: route every read and write through one shared check that denies by default, and test it with two customer accounts trying to see each other's data. Broken access checks are the most common serious flaw in web apps, and better login does nothing about them; see Authorization: what's real.
2. Build or buy: don't write sign-in, SAML or account recovery yourself; buy a hosted service or run a maintained open-source server. Spend your engineering on organizations, roles and the enterprise setup flow, since basic sign-in is free up to tens of thousands of users at most vendors.
3. Offboarding: when a customer's directory removes someone, revoke their sessions, refresh tokens, API keys and app grants as well. Deactivating the user record doesn't recall tokens already issued, so a former employee's laptop can keep working until they expire. See step 5 of How an enterprise customer gets connected, step by step.
4. Recovery and help desks: offer passkeys, then close the weaker doors beside them: SMS fallback, email-only resets and support staff who reset accounts without strong checks. Attackers take the cheapest path in, and several of the costliest incidents since 2023 started at a help desk.
5. Pricing: model your bill on each vendor's meter before you choose, because some charge per user and others per enterprise connection. For the same app, list prices run from about $2,000 a year to over $200,000; the math is in How the money moves.
6. Liability: plan as if a takeover is yours to pay for. The identity vendors' terms I read cap their liability at a year of fees with no exception for breaches, and make you responsible for your users' credentials; see Liability allocation.

This guide starts where onboarding checks end: verifying that a person or business is real is in Identity and trust: KYB, KYC and ongoing monitoring. Permissions and machine identities inside cloud accounts, including the Snowflake and Storm-0558 cases, are in Cloud security (CNAPP), and agent tool security is in AI agents: orchestration platforms. Agents acting for users will get their own guide on agent identity and delegated access; here they appear only as the newest machines that sign in.

The main players

The companies behind the diagram's parties, layer by layer, in no particular order.

How they make money:

The incumbent grows steadily and the independents sell at very different prices. Okta's revenue reached $2.9 billion in the year to January 2026, up 12%, with customer identity around 41% of its contract value. Palo Alto Networks closed its roughly $25 billion purchase of CyberArk in February 2026, while Stytch, valued at $1 billion in 2021, was reportedly sold to Twilio for about $104 million. Big money is going to machine identity and security platforms, and much less to login on its own.

As of October 2026. Private-company figures are self-reported or from the press, and several of these companies changed owners in the last year, so treat the list as a map to check.

Back to the project app. Ana, a planner at one of its enterprise customers (a logistics company with 2,000 staff on Microsoft Entra), types a work email on the login page. The app's identity provider, WorkOS or Auth0 for example, sees that the domain uses SSO and hands the sign-in to Entra, which checks Windows Hello on Ana's laptop and returns a signed SAML response with Ana's name and groups. The identity provider turns that into the app's session, and when Ana opens a project board, the app asks its permission service whether Ana may edit it. When Ana changes jobs in March, Entra deactivates the account through SCIM. Had an infostealer copied the session cookie from Ana's home laptop the week before, the attacker would have walked in with MFA already done.