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.

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.

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.