Bottom line up front: before you wire SSO across your WMS, OMS, and TMS, don't start with the protocol docs. Spend one afternoon building a three-column spreadsheet — person, role in each system, who deactivates the account when they leave. If you can't fill out that sheet, it doesn't matter whether you pick SAML or OIDC. I've watched this exact failure three times, and the breaking point is always the same: the identity provider connects cleanly, and the role mapping on the business side is a mess.
Why this always blows up the night before go-live
September 2023. A 60,000-square-foot 3PL in Southern California, going live with WMS, OMS, and TMS in the same week. To keep things simple, the client gave the floor a single shared username and password across all three systems. Sounds efficient, right?
It blew up on day three. A customer service rep who could view orders in the OMS could also edit carrier rates in the TMS — because the "CSR" role meant completely different things in each system, and the shared login inherited the broadest permissions of the three. The owner asked me: "Isn't this what single sign-on is? Why is it getting messier?" My answer: that's not single sign-on. That's a single point of failure with a login screen.
How we saved it was ugly but effective: we froze 40-odd shared accounts overnight, rebuilt 120 individual accounts mapped person-to-system-to-role, got the business running, then spent two weeks aligning the role matrices and connecting everything to a single identity source. That project burned one lesson into me: SSO answers "who are you." Authorization answers "what can you do." Those are two different problems, and you should never outsource the second one to the first.
The checklist: zero to SSO, step by step
Step 1: Inventory every account. Export all accounts from all three systems into a spreadsheet with three columns: username, system, current role. Flag three types — zombie accounts from departed employees (nearly every project has 5–10% of them), shared "public" logins (most common on picking tablets), and over-privileged "god accounts." If these aren't cleaned up before go-live, SSO changes nothing.
Step 2: Build the role mapping matrix. Rows are business roles (picker, CSR, dispatcher, warehouse supervisor, finance, IT admin); columns are the three systems; each cell says exactly which buttons that role can click in that system. Watch out: a "dispatcher" in the TMS and a "dispatcher" in the WMS are probably not the same thing. Same name, different powers. Get the business owner to sign this sheet. No signature, no go-live.
Step 3: Pick your identity source. If the company already runs a corporate identity system, use it as the identity provider — don't build a second one. Only if there's nothing in place do you move to the protocol decision in step 4.
Step 4: Pick the protocol. New systems: OIDC first. Legacy systems: check for SAML 2.0 support. Plenty of traditional WMS products only speak SAML — don't force OIDC on them and rewrite their code. Protocol adaptation rabbit holes are deeper than they look.
Step 5: Map the user attributes. Decide what the identity provider passes downstream: employee ID, email, department, role. Pass at least one stable, globally unique identifier — employee ID, not email, because emails get renamed. For each field, name the authoritative source: department comes from HR, full stop.
Step 6: Wire up the offboarding flow. Account deactivation must hook into HR's termination process, with "disabled on the last day" as the target. Can't automate it? Then IT manually reconciles the termination list every Friday afternoon. I've seen this hole three times. In early 2024, a home-goods e-commerce warehouse did a permission audit six months after a clean SSO launch and found a dispatcher who'd quit three months earlier could still log into the TMS and look up carrier rates — because nobody had ever synced HR's termination list to IT.
Step 7: Roll out in stages. Pilot with 5–10 IT staff for a week, then one warehouse, then everyone. Keep the old login path available as a rollback during the pilot — that line sits at the top of my go-live-night checklist, permanently.
Do the math first: SAML vs. OIDC vs. homegrown
| SAML 2.0 | OIDC | Homegrown accounts | |
|---|---|---|---|
| Best for | Legacy systems, traditional WMS/ERP | New systems, cloud-native apps | Tiny teams with one or two systems |
| Implementation effort | Medium (verbose XML config) | Lower (JSON, mature ecosystem) | Low up front, high later |
| Ongoing maintenance | Low (mature standard) | Low | High (password policy, audit, MFA — all DIY) |
| Mobile/tablet support | Weak | Strong | Depends on your code |
| Long-term total | Old but stable | Default choice for new projects | Loses money past two systems — don't |
The decision framework is simple: if any of the three systems only supports SAML, go all-in on SAML. All new systems? OIDC. Consider homegrown only if you're certain you won't exceed two systems in the next two years. The real cost of a homegrown account system isn't the build — it's the day you connect system number four and discover the first three each invented their own password policy.
Go-live night checklist: every failure lives here
- Delete the test accounts. Nearly every project turns up three to five test01-style accounts still alive the night before go-live.
- Don't route admin accounts through SSO. Keep at least one local super-admin account per system for the day the identity provider goes down. Write the password on paper and lock it in a safe — yes, it's primitive, and yes, it has saved a go-live.
- Align session timeouts across the three systems. WMS at 8 hours and TMS at 30 minutes will drive dispatchers insane. Standardize on 4–8 hours, with a separate policy for peak-season tablets that never lock.
- Test the dead-zone scenario. When the warehouse Wi-Fi drops, the SSO redirect page won't load on the tablet and the picker stands in front of the rack staring at nothing. The degraded-mode fallback must be tested for real, on the actual floor.
- Make sure the audit logs can be joined. When something breaks, you need to answer "what did this user change in the TMS at 2 p.m. yesterday" — and all three systems' logs must carry the same user identifier.
One contrarian note to close: a lot of people feel safer after SSO goes live. The truth runs the other way — SSO turns "one key, one door" into "one key, three doors," so a lost key costs three times as much. MFA isn't optional with SSO; it's part of the package. Too much friction? Then enforce it at least for admins and finance roles.
One thing you can do tomorrow: export the accounts from all three systems and lay them out in the three columns from step 1. The first truth you'll discover is usually this — the 80 accounts you thought you had are actually 110.
By Lin Xiao, WMS Implementation Consultant
