SSO for AI Apps: Protocols, Agent Access and Security

TL;DR: SSO for an AI app covers two jobs: how people sign in through their company identity provider, and how the agent gets limited access to other systems on their behalf. Build on OpenID Connect first and add SAML when a customer needs it. Give agents delegated, short-lived tokens or their own narrow identity, and keep secrets away from the model. Log every action, enforce MFA and plan identity at the architecture stage, because retrofitting it costs far more.

Single sign-on (SSO) for an AI app lets people sign in with the work account their employer already manages. They don't need another username and password. An AI app gives SSO a second job too. It has to decide what the AI agent can do for that person. Get the first part right and enterprise buyers can onboard. Get the second part right and the agent can't reach data its user couldn't.

This guide is for founders and CTOs building or extending an AI product in Australia. It covers the protocol choice, agent flows, mobile, a build order, and the security and privacy points to settle before launch.

The short version

• SSO for an AI app covers two things: how people sign in through their company identity provider, and how the agent gets limited access to other systems for them.
• For a new product, Microsoft recommends OpenID Connect (OIDC) for cloud-native, single-page and mobile apps. Add SAML when an enterprise customer needs it.
• Agents should never share a user's password or hold a static key. Use token exchange or delegated flows. Check every token's issuer, audience and expiry.
• Log access, enforce MFA and give out the least access you can. Australian Privacy Principle 11 expects reasonable steps to protect personal information.
• Design identity at the architecture stage. Adding it to a finished product costs far more.

What SSO means for an AI app

In a normal SaaS product, SSO is one flow. The user opens your app and is sent to the company identity provider (IdP). They sign in there. They come back with a signed assertion or token that proves who they are. Your app trusts the IdP and never sees a password.

An AI app adds more actors. There is the person, your backend, the agent layer, and the tools and data the agent calls. Auth0's AI documentation splits these into three cases:

• Interactive users sign in with enterprise SSO.
• Machine-to-machine agents act as themselves. They use Client Credentials, mutual TLS or Private Key JWT.
• Delegated agents act for a user. They use on-behalf-of or token-exchange flows.

The split matters because each case has a different risk. A user who signs in through SSO has the access their employer gave them. A delegated agent should hold a smaller slice of that, for a short time. A machine agent needs its own narrow identity. It should never borrow a person's.

To see where identity sits in the wider build, read our layered guide to AI platform architecture. It shows where the sign-in layer meets the model, data and integration layers.

SAML or OpenID Connect: which to support

Both are SSO protocols. SSO is the outcome. SAML and OIDC are two ways to get there. Microsoft's decision guide describes SAML 2.0 as XML-based and well established in big companies. OIDC sits on top of OAuth 2.0 and uses JSON Web Tokens. It suits modern apps, mobile apps and microservices.

For a new AI product, we follow Microsoft: build on OIDC first. It shares its roots with the OAuth tokens your agent uses to call tools. One identity model then covers both people and agents. Add SAML when a customer's security team asks for it. Larger enterprises and some government buyers will. If you start on a standards-based layer, adding SAML later is setup and testing work. It isn't a rewrite.

How agents fit into the sign-in flow

This is where AI apps differ most from ordinary SaaS. It's also where most of the new risk sits. Three patterns cover nearly every case.

Delegated access with token exchange

The user signs in through SSO. The agent then needs to call another service for them. Your backend swaps the user's token for a new, narrower one. The agent never sees the user's credentials. The other service can see who the action is for. Curity's write-up on SSO for AI agents with OpenID Connect shows how OIDC and token exchange keep a user's identity intact across separate trust domains.

Enterprise-controlled app-to-app access

Sometimes your AI app needs to reach another app the customer owns, like a document store, CRM or ticketing tool. The customer's IdP can govern that link. Under Cross App Access, the user signs in to your AI app. Your app swaps the identity token for an identity assertion. The other app's authorisation server checks it and issues an access token for its API. The customer's IT team sets the rules once at the IdP. Users don't click through consent screens and leave long-lived keys behind.

Agents with their own identity

Background agents run without a user present. An overnight reconciliation job is one example. Give them their own credentials and their own narrow permissions. Prefer mutual TLS or Private Key JWT over shared secrets where the platform supports them.

Some agents need their own mailbox too, to get confirmations or hand work to a person. Treat that mailbox as another delegated resource with its own scope. Purpose-built email infrastructure for agents sets up inboxes through code, with per-mailbox quotas and multi-tenant controls. That keeps the access apart from any person's account.

Securing tokens and tools

Agents that call tools through the Model Context Protocol (MCP) or direct APIs add more places for a token to go wrong. Microsoft's Azure MCP security guidance gives a checklist you can use on any stack:

1. Check every incoming token's issuer, audience and expiry before a tool runs.
2. Use audience-bound tokens. A token issued for one service then can't be replayed against another.
3. Match redirect URIs exactly against the ones you registered.
4. Ask for consent per client.
5. Use PKCE for authorisation-code flows.

We add one rule of our own. The language model should never handle raw credentials. Tokens live in your backend. You add them at the moment of a tool call. They never go in a prompt, a log line or the model's context window. A model can be tricked into repeating anything it has seen.

Adding SSO to a mobile AI app

Yes, you can add SSO to a mobile app. Microsoft says OIDC fits mobile apps and lists native support for mobile and single-page apps. That's one more reason to lead with it. The flow is what changes. A mobile or browser client should use the authorisation code flow with PKCE, because it can't keep a client secret safe. The Microsoft Authentication Library for JavaScript documents this for browser apps. For Node.js it lists device code, client credentials, refresh-token, on-behalf-of, managed identity and interactive flows.

On iOS and Android, the app opens the system browser or a secure in-app browser session. The user signs in with their company account. The app gets the authorisation code through a registered redirect. Test the awkward cases early: an expired session, a user removed from the company directory, and a phone that loses signal halfway through sign-in. If you're planning native builds, our mobile app development work includes this kind of sign-in design.

A build order that works

This order keeps identity from becoming a late surprise.

1. Decide your tenancy model. Will each customer organisation be its own tenant with its own IdP connection? For B2B AI products the answer is usually yes. The Australian AI Dojo platform's technical design is one public example. It's a multi-tenant Microsoft Entra application. Customer organisations approve access from their own tenants, and the platform holds no local usernames or passwords.
2. Choose build or buy for the identity layer. Writing SAML and OIDC handling yourself is rarely worth it. A managed identity service or a mature library gives you tested protocol handling. Your team's time goes to the product.
3. Register the app with the customer's IdP. Create the app registration and set redirect URIs. Define the claims you need, like user ID, email, roles or groups. Agree who holds secrets and how they rotate.
4. Map identity to permissions. SSO tells you who someone is. Your app still decides what they can see. Map IdP groups to roles. Make the user's role a ceiling for the agent, never a floor.
5. Add provisioning and offboarding. When someone leaves a customer's company, their access should end fast. So should any agent sessions acting for them.
6. Test with real customer IdPs. Test more than one provider and one deliberately broken setup. Check how the app finds the right company sign-in if one user could belong to several organisations.
7. Write the setup guide for customer IT. A short sheet with the metadata URL, redirect URIs and supported claims shortens enterprise sales cycles.

Many Australian organisations already run on Microsoft's identity platform. The Australian Signals Directorate's Blueprint for Secure Cloud describes Microsoft Entra ID as an identity and access-management solution. It links third-party apps with multifactor authentication, automatic provisioning, Conditional Access and single sign-on. Supporting Entra ID well is a sensible first target for an Australian B2B product. That's especially true if you sell to government or regulated industries.

Security and privacy points for Australian products

SSO puts sign-in in one place, so the controls around it matter more, not less.

• Multi-factor authentication. The Australian Cyber Security Centre notes that mobile authenticator apps can supply time-limited one-time passwords as a second factor. Enforce MFA at the IdP and on your own admin accounts.
• Roles and logging. ACSC guidance on cloud computing security advises identity and access management with MFA and roles with different levels of access. It also advises detailed, time-synced logs and real-time alerts for cloud accounts, especially admin ones. For an AI app, log which agent acted, for which user, on which resource.
• Least privilege. The OAIC's review of access controls notes that logical access controls should grant access only to the level required. That applies to agents as much as to staff.
• Personal information. The OAIC says APP 11 requires reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, change or disclosure. If your agent reads customer records, identity design is part of meeting that duty. Our AI software compliance overview covers the wider picture. For the agent side, the AI Orchestrators guide to AI agent security goes deeper.

Whether the APPs apply to your business depends on its size and activities. Check with a privacy lawyer before you lock in a design.

Our take

We've shipped 200+ apps, and one pattern shows up often. Identity gets treated as a feature to bolt on after the AI works. It belongs in the foundation of the platform. Teams that plan it early tend to have a smoother buyer security review, because there are answers waiting instead of gaps.

We hold three firm opinions. First, start with OIDC and add SAML on demand, not the other way round. Second, give agents the narrowest identity that lets them do the job, and trace every action back to a user or a named agent. Third, keep the model away from secrets entirely. These choices cost little in week one. They can save a rebuild in year two.

We also see vibe-coded prototypes with a single shared login and a static API key. That's fine for a demo. It's unsafe for customers. Moving to a multi-tenant design is a well-understood job. Our case study on taking an MVP to a white-label AI SaaS shows how that move looks in practice.

Getting SSO built into your AI product

Planning a new AI platform, or adding agents to an existing SaaS or mobile app? We design and build sign-in, agent permissions and the data and automation layers around them as one system. See our AI platform development service. Or read how we approach adding AI to an existing app before you brief us.

Frequently asked questions

What is the difference between SSO and SAML?

SSO is the user experience: sign in once with a company account and reach several apps. SAML is one protocol that delivers it, using XML assertions. OpenID Connect is the other common option, built on OAuth 2.0 and using JSON Web Tokens.

Can you SSO into a mobile app?

Yes. OIDC supports mobile apps natively. The app uses the authorisation code flow with PKCE, opens a secure browser session for the company sign-in, and receives the result through a registered redirect.

Do AI agents sign in with SSO like users do?

Not directly. A user signs in through SSO, then the agent acts through delegated flows such as token exchange, receiving a narrower, short-lived token. Agents running without a user should use their own machine credentials with limited permissions.

Should a new AI app support SAML or OIDC?

Build on OIDC first, as Microsoft recommends for cloud-native and mobile apps. Add SAML when an enterprise customer or legacy identity provider requires it.