How to Set Up Single Sign-On for Amazon Business

Single sign-on is one of the few Amazon Business features that is genuinely infrastructure rather than configuration, and it is worth being clear about who should implement it before describing how.

Should you do this at all?

Two conditions have to hold:

1. You already run an identity provider. Okta, Microsoft Entra, or similar. SSO federates against something; if there is nothing to federate against, there is no project here.
2. User administration is a real burden. Amazon lets you invite up to 20 users at a time by email, plus invite links and spreadsheet uploads. For most organizations that is entirely sufficient — see how to add users to Amazon Business.

If both hold, SSO is one of the highest-value things you can configure. If neither does, close this page and spend the time on approval workflows instead.

What you are actually buying: the leaver problem

Joiners are easy. Somebody wants access, they ask, they get it. The control failure is always on the other end.

Without SSO, removing a departing employee's Amazon Business access depends on somebody remembering. Amazon's removal path is Business Settings → Users → Actions → Remove from group, repeated for each group the person belongs to. In a large organization with turnover, that gets missed.

With SSO, access is a function of the directory account. Disable the directory account and the access goes with it. Add SCIM on top and the user record itself is provisioned and de-provisioned automatically.

There is a second, quieter benefit for anyone paying for a membership: stale users inflate your seat count, and the Prime Business terms state your fee increases automatically if your user count moves you into a higher plan. Automated de-provisioning is, among other things, a cost control — see renewal and refunds.

Who is allowed to do this

A detail that stops more SSO projects than any technical problem: the person who wants to configure it usually cannot see the settings. Amazon publishes 5 user roles, and one of them exists precisely for this work.

The Tech user role, in Amazon's own description, manages domain names, authentication methods, API keys and IT system integrations including single sign-on. That is the role your identity engineer needs before they open Business Settings — not administrator, and certainly not requisitioner.

Two rules make this workable in practice. Amazon states that a person can hold multiple user roles, so the account administrator can also hold Tech user rather than handing the account over. And only administrators can add or remove other administrators, so if the person who set the account up has left, sort that out first — changing the account administrator covers the order it has to be done in. Role assignment itself sits with the administrator on the Users page, alongside the 3-day invitation reminder and the rest of the user tooling in multi-user accounts and approvals.

Sort out domain ownership first

SSO federates one business account. It does nothing for the three other accounts your staff created on the company domain before IT got involved, and in a mid-sized organization those almost always exist. Amazon publishes a separate toolset for that problem — Account Authority — and it is the right thing to run before a federation project rather than after:

• Account creation approval. Require approval before anyone in your organization can create a business account, so rogue spend never starts.
• Consolidate accounts. Pull business accounts your buyers already created into the official account, centralizing visibility and spend.
• Automatic user creation. Create business accounts for employees by bulk upload instead of sending, managing and tracking individual invitations.
• Retail account conversion. Notify employees creating an ordinary Amazon retail account on a verified domain to use the organization's business account instead.

Consolidate and gate first, federate second. Otherwise you finish the SSO rollout with a clean login experience for the population that was already visible and no change at all for the spend that was not — multiple accounts covers how organizations end up in that state.

The setup

1. Confirm you actually need SSO. You need an existing identity provider and enough users that manual account administration is a burden. If you have eleven people and no IdP, email invitations are the right tool and this whole exercise is overhead.
2. Involve IT before Business Settings. This is a federation configuration, not a purchasing setting. Whoever administers your identity provider needs to be part of it from the start.
3. Sign in as an Amazon Business administrator. SSO configuration lives behind Business Settings, which requires the administrator role.
4. Open Business Settings. From the Your Account menu, go to Business Settings.
5. Under System integrations, select Single Sign-On (SSO). This is where Amazon groups SSO alongside its other integration options.
6. Follow the steps on the setup page. Amazon notes that if you have questions during setup, the Single Sign-On setup guide is available from any of the Single Sign-On setup pages.
7. Add SCIM provisioning once SSO is active. Amazon states that if you activate SSO on your Amazon Business account you can then set up SCIM, an industry-standard protocol that automates the exchange of data between identity providers and service providers. Amazon states SCIM is available for Okta and Microsoft Azure.
8. Test the leaver process, not just the joiner process. The joiner path gets tested by everyone. Confirm that disabling a directory account actually removes Amazon Business access, because that is the control you are buying.

SCIM, and what Amazon publishes about it

Amazon's description is precise, so we will quote its substance rather than paraphrase loosely. SCIM is an industry-standard protocol that automates the exchange of data between identity providers (IdPs) and service providers (SPs) like Amazon Business. Amazon states SCIM can be set up if you activate SSO on your Amazon Business account, and that it is currently available for Okta and Microsoft Azure, with Azure noted as being in the pilot stage as of October 2023.

Two practical implications:

• SSO first, SCIM second. They are sequential, not alternatives.
• Check current availability for your IdP. The Okta and Azure list is what Amazon publishes; if you run something else, confirm with Amazon Business rather than assuming.

We are deliberately not publishing configuration values, attribute mappings or metadata URLs. Amazon provides a setup guide inside the flow, those details are environment-specific, and getting federation settings from a third-party article is how outages happen.

What changes for the people signing in

Worth setting expectations before you announce it, because two things people assume will change do not.

Account switching is not part of this. Amazon states the switcher is currently only available to business accounts using free email domains such as Gmail or Yahoo. An SSO deployment runs on a company domain by definition, so staff who also hold a personal Amazon account will be signing in and out rather than toggling. That is the correct outcome for a business account, but it is the thing people complain about in week one — logging in to Amazon Business is the page to send them.

One address, one business account. Amazon states an email address can be associated with only one business account at a time. Anyone already sitting on a second business account under their work address has to be moved off it before federation reaches them, which is the practical reason the Account Authority step above comes first.

SSO is not punchout

These get conflated in almost every write-up, so to be explicit:

• SSO — authentication. Amazon describes it as giving buyers secure, one-click access to Amazon Business.
• Punchout — workflow. Amazon describes it as beginning your buying journey in your e-procurement system, then punching out to the Amazon Business website.

You can run either without the other. Amazon states it offers integrations with more than 300 e-procurement, expense management, identity provider and e-sourcing systems, plus APIs for custom integrations — SSO sits in the identity provider portion of that catalog. See punchout and procurement integration.

What to configure alongside it

SSO answers who a person is. It does not answer what they may do, where they may ship, or who approves their orders. Those remain account settings, and they should be in place before you federate a large population into the account:

• Groups, per site or department, which scope shared addresses and invoice templates.
• Roles, so only administrators and finance users reach invoices and reporting — invoices and receipts.
• Shared addresses, so buyers cannot ship to arbitrary destinations — multiple shipping addresses.
• Approval workflows, free on the account, and Guided Buying if the buyer population is large enough that review is impractical — Guided Buying and purchasing policies.

The organizations that most often want this are manufacturers and large multi-site operators, where Amazon itself positions SSO as enabling controlled and secure access — see manufacturing and industrial and government and public sector.