SSOGEN / SSO Explained: The Standards Behind Single Sign-On, MFA and AI Agent Identity

Learn

SSO Explained: The Standards Behind Single Sign-On, MFA and AI Agent Identity

Single sign-on lets one trusted identity provider vouch for you, and SAML, OpenID Connect, SCIM and MFA are the standards that carry that trust.

Updated

SSO explained: one identity provider signs a person in and many applications trust the result
Start with the idea, then follow each standard to its guide.

This guide is SSO explained from the protocols to the controls. Single sign-on (SSO) means a user authenticates once, to one trusted system, and then opens many applications without signing in to each. That system is the identity provider, and the applications trust what it tells them.

Everything else is detail: how that trust travels, stays current and gets stronger. Product steps are in the documentation, and each topic below links to them.

Topic One-line answer In SSOGEN
SSO Sign in once, open many applications What SSOGEN is and single sign-on software
SAML XML sign-in statements for enterprise and SaaS apps Register a SAML application
OpenID Connect Sign-in on top of OAuth 2.0, with a signed ID token Register an OpenID Connect application
SCIM A standard for creating and switching off accounts Inbound provisioning
MFA A second proof that it is the right person Multi-factor authentication
AI agent identity Knowing which agent called, for whom, and stopping it AI agent identity

How SSO works in three steps

  1. The application redirects the user to the identity provider.
  2. The provider authenticates the user, applies its policies and second factors, and returns a signed statement of who the user is.
  3. The application verifies the signature and starts a session.

The user enters the password once, at the provider. The application never sees it.

SAML: signed assertions for enterprise and SaaS applications

SAML 2.0 carries the signed statement as an assertion.

  • Identity provider. It authenticates the user.
  • Service provider. The application identifies itself by an entity ID and a reply address.
  • Common failure. Most SAML failures are a mismatch in one of those two values, which is why SSOGEN matches them exactly.

Use SAML when an application’s settings page asks for identity provider metadata, an entity ID or a sign-in URL. The SAML guide lists every field.

OIDC: sign-in built on OAuth 2.0

  • OAuth 2.0. It grants one program limited access to another.
  • OpenID Connect. It adds a signed ID token that identifies the user, which makes OAuth usable for sign-in.
  • In SSOGEN. Every application uses the authorization code flow with PKCE, not the implicit or hybrid flow.

Use OpenID Connect when an application asks for a client ID, a client secret or an issuer URL. If it supports both protocols, either works. Choosing how to connect an application lists the questions to ask, in order.

SCIM: keeping accounts in step

Sign-in is half of the job. When an employee leaves, the accounts in every application must be removed as well.

  • Standard. SCIM 2.0 is the standard HTTP interface for that.
  • Inbound. An HR system can push users into SSOGEN.
  • Outbound. SSOGEN then creates, updates and deactivates accounts in applications that support SCIM.
  • Records. The SSOGEN Directory shows how SSOGEN stores user records.

MFA types and what each one is worth

Method What the person does Strength note
Authenticator app (TOTP) Types a six-digit code that changes every 30 seconds The default and the strongest of the code methods
Passkey Approves with the fingerprint, face or PIN of the device in their hand Cannot be phished, nothing is typed
Recovery code Types one of a set of single-use codes For a lost phone
Text message Types a code sent by SMS Weaker, can be intercepted
Email Types a code sent to their address Weakest, use only as a fallback
  • NIST position. NIST SP 800-63B does not accept email as a second factor and restricts SMS.
  • SSOGEN default. SSOGEN keeps both disabled unless a policy lists them.
  • Phone app. The SSOGEN Authenticator is a phone app for iPhone and Android that approves sign-ins by number and shows TOTP codes.
  • Other methods. MFA software covers the other methods.

AI agent identity: the same questions for software

An AI agent that calls your systems raises the questions SSO answered for users: which agent is calling, on whose behalf, with what permissions, and how to stop it. Long-lived keys answer none of them.

The controls that close that gap:

  • Each agent has its own identity, with named owners.
  • Credentials expire within minutes.
  • A user consents before the agent acts on their behalf.
  • Sensitive scopes require approval.
  • Every decision is recorded.

Two standards apply: OAuth 2.0 token exchange (RFC 8693), for acting on behalf of a user, and DPoP (RFC 9449), which binds a token to the agent’s key. AI agent identity shows how SSOGEN does it.

Explainers by topic

Single sign-on basics

Standards: SAML, OpenID Connect and OAuth 2.0

Provisioning and MFA

Directories and access control

Oracle and ERP sign-in

Attacks and risks

Free tools you can use in the browser (all of them, with a full list on the tools page)

AI agents and machine identity

Questions people ask

Is SSO the same as MFA?

No. SSO reduces how often users sign in, and MFA strengthens each sign-in. They work together, and a policy can require a second factor only for sensitive applications.

Do I need SAML and OpenID Connect both?

Usually not. Use whichever protocol each application supports. SSOGEN supports both, so a mix is fine.

Is a passkey MFA?

A passkey is a phishing-resistant sign-in on its own. A policy can require “a passkey or security key” for sensitive applications.

Where to go next