Four companies. Combined market cap north of $200 billion. Four completely different codebases, written in different languages, by different teams, on different continents. And yet when you sit down to authenticate against their APIs, you hit the exact same bugs.

Not similar bugs. The same bugs. Token refresh race conditions. Scope confusion. Session expiry mid-operation. Undocumented CSRF requirements. The kind of problems that make you wonder whether there is a single cursed OAuth tutorial that every enterprise CAD company forked in 2014 and never updated.

We spent weeks collecting developer complaints, forum posts, and Stack Overflow threads across Autodesk APS, PTC Onshape, Dassault 3DEXPERIENCE, and Siemens Teamcenter. The results are damning --- and they reveal something important about why these problems persist.

Related: This post extends our earlier Authentication Chaos article with structured cross-vendor comparison data.

The Four-Vendor Breakdown

Autodesk APS

The most common question in the APS developer forums is not about modeling, rendering, or data management. It is: “Do I need 2-legged or 3-legged auth?”

The confusion is structural. Two-legged tokens act on behalf of the application. Three-legged tokens act on behalf of a user. The API surface is the same, but the permissions model is completely different, and the documentation does not make it obvious which endpoints require which flow. Developers routinely burn hours testing one flow, getting 403s, switching to the other, getting different 403s, and eventually discovering they need a specific scope they did not know existed.

Autodesk APS --- Authentication Pain Points

2-Legged vs 3-Legged Confusion

The single most asked question in APS forums. Same endpoints, different auth flows, no clear guidance on which to use when.

Token Refresh Race Conditions

Concurrent requests trigger simultaneous refresh attempts. The first one wins; the rest get invalidated tokens. Classic TOCTOU bug at the API layer.

Scope Explosion

Over 40 scopes. No single reference for which endpoints require which scopes. Trial and error is the de facto documentation.

Inconsistent Rate Limiting

Official limit is 100 req/min, but there is no standardized 429 response across APIs. Some return 429, some return 503, some just hang.

The race condition problem deserves special attention. When you have a long-running automation --- say, translating 200 models overnight --- your token will expire mid-run. If two threads notice the expiry at the same moment and both attempt to refresh, the second refresh invalidates the token the first one just obtained. In RAPS, we solve this with a Mutex + Notify pattern in raps-kernel: a single refresh is allowed at a time, and all waiting threads receive the fresh token once it arrives.

PTC Onshape

Onshape gets credit for being cloud-native from day one. That does not save it from OAuth sins.

PTC Onshape --- Authentication Pain Points

Trailing = in Client Secrets Breaks URL Encoding

Base64-encoded secrets frequently end with = or ==. If you do not URL-encode them, the OAuth token exchange silently fails with an unhelpful error.

Encoding Ambiguity

No clear documentation on whether to use form encoding, query-string encoding, or Base64 for different auth parameters. Developers discover the answer by trial and error.

Deprecated API Keys Still in Docs

API key authentication is deprecated but still present in official documentation and tutorials. New developers follow deprecated guides, then have to start over.

Session Memory Leaks

Long-running automations that maintain OAuth sessions leak memory. Session management was designed for interactive browser use, not headless pipelines.

The trailing = problem is almost comical. A developer shared this on the Onshape forums: “The body of the form needs to contain the client ID, client secret, authorization_code… Each parameter needs to be URL encoded --- especially important for the Client ID and secret since either or both may contain multiple trailing ’=’ characters.” The fix is one line of code. Finding it costs an afternoon.

Dassault 3DEXPERIENCE

If Autodesk’s auth is confusing and Onshape’s is finicky, Dassault’s is an endurance test.

Dassault 3DEXPERIENCE --- Authentication Pain Points

Five Login Contexts in One Session

3DPassport requires separate authentication for: the partner platform, the commercial platform, the support system, your tenant, and your application. One developer reported logging in five times in a single hour.

Undocumented CSRF Requirements

API calls require CSRF tokens, but this requirement is not documented in the API reference. Developers discover it when POST requests fail with opaque 403 errors.

Session Cookies Expire Mid-Operation

No refresh mechanism for session cookies. Long operations simply fail partway through, with no recovery path other than re-authenticating and restarting.

SOLIDWORKS Crashes on Auth Failure

When 3DPassport authentication fails mid-save, the error cascades into SOLIDWORKS itself, crashing the desktop application. Auth failures become data-loss events.

The SOLIDWORKS crash scenario is the most severe failure mode in this entire comparison. An authentication timeout during a cloud save can crash the desktop application. This means a back-end infrastructure issue --- an expired session cookie --- can destroy work-in-progress CAD data. Auth is not just a developer convenience problem here; it is a data integrity problem.

Siemens Teamcenter

Teamcenter is the oldest platform in this comparison, and it shows. Authentication is not one system; it is at least two, running in parallel, with different rules.

Siemens Teamcenter --- Authentication Pain Points

SSO Configuration Labyrinth

Six or more parameters required: tcsso.login_service.proxyURL, discriminators, endpoint configs, credential managers, external IdP settings, protocol flags.

SoaRuntimeException on Login

This exception is so common it has its own multi-page troubleshooting guide. It is the “have you tried turning it off and on again” of Teamcenter development.

Two Parallel Auth Systems

REST API auth and IIOP (legacy SOA) auth are separate systems with separate configurations. Migrating between them is a project in itself.

No Token Flow for CI/CD

There is no headless, token-based authentication flow suitable for CI/CD pipelines. Automation requires either interactive login or fragile session cookie management.

The CI/CD gap is particularly painful. Modern software development assumes you can authenticate a headless process with a token or service account. Teamcenter’s auth model was designed for a world where every user sits at a workstation and types a password. Adapting that to GitHub Actions or Jenkins requires workarounds that nobody wants to maintain.

The Cross-Vendor Auth Failure Matrix

Every column below represents a billion-dollar software company. Every filled cell represents a problem that has persisted for years.

Auth Problem	Autodesk APS	PTC Onshape	Dassault 3DX	Siemens TC
Multiple auth flows with unclear guidance	YES	YES	YES	YES
Token refresh race conditions	YES	YES	---	---
Session expiry mid-operation	YES	YES	YES	YES
Scope/permission confusion	YES	---	YES	YES
Undocumented auth requirements	YES	YES	YES	YES
Deprecated auth still in docs	---	YES	---	YES
Auth failure crashes desktop app	---	---	YES	---
No headless/CI-CD auth flow	---	---	YES	YES
Parallel legacy + modern auth systems	YES	---	YES	YES

Reading the matrix: “YES” means the problem is documented in developer forums, bug reports, or official troubleshooting guides. ”---” means we found no evidence of that specific failure mode for that vendor.

Look at the first row. Every single vendor has multiple authentication flows with unclear guidance on when to use which. Look at the third row. Every single vendor has sessions that expire mid-operation. These are not coincidences.

Why This Is Structural, Not Accidental

It is tempting to blame individual engineering teams. But when four independent organizations produce the same bugs, the cause is not incompetence. It is incentive structure.

Enterprise sales drive SSO complexity. Large customers demand SAML, OIDC, LDAP, and Active Directory integration. Each integration adds auth flows. Nobody is incentivized to remove old flows once new ones ship.

Multi-tenancy demands layered auth. Dassault’s five-login problem exists because 3DEXPERIENCE serves partners, customers, support staff, and end users from a single platform. Each audience gets its own auth context. The developer experience is collateral damage.

Legacy compatibility prevents cleanup. Siemens cannot kill IIOP auth without breaking every Teamcenter deployment that has not migrated to REST. PTC cannot remove API keys without breaking tutorials that thousands of developers have bookmarked. The deprecated paths stay, and new developers trip over them.

Auth is nobody’s product. No CAD company has a “Developer Authentication” product manager. Auth is infrastructure --- owned by security teams who optimize for compliance, not for developer experience. The result is systems that pass security audits and fail usability tests.

The uncomfortable truth:

These are not bugs. They are the predictable outcome of organizations that sell to CIOs, not to developers. Auth will stay broken until developer experience becomes a line item in enterprise contracts.

What RAPS Does Differently

RAPS cannot fix every vendor’s auth. But it can demonstrate what auth should feel like by solving it completely for one platform.

# What takes 50+ lines of OAuth boilerplate across any platform:
raps auth login --preset all

# Token status across all flows:
raps auth status

# Automatic refresh, race condition handling, secure keyring storage
# All handled by raps-kernel --- the same core used by CLI, MCP server, and cloud

Three commands. Zero boilerplate. Here is what happens under the hood:

Problem	Industry Standard	RAPS
Token acquisition	Base64 encode creds, POST to vendor endpoint, parse JSON, store result	raps auth login
Token refresh	Implement expiry checks, handle refresh tokens, manage race conditions manually	Automatic (Mutex + Notify pattern)
Credential storage	Build secure storage, handle OS keychain differences, encrypt at rest	Built-in keyring integration
Scope selection	Read docs, guess, test, fail, read forums, try again	—preset all (or granular —scopes)
CI/CD integration	Custom scripts, session hacks, stored cookies	raps auth login (2-legged, headless)

This is not a theoretical comparison. Every RAPS auth claim is tested in CI on every release. The same raps-kernel auth module powers the CLI, the MCP server, and the cloud service. One implementation, one set of tests, one set of race condition fixes.

What Comes Next

This is the first post in the Cross-Platform Pain series. The auth problem is just the surface. Next, we will look at why no CAD/PLM vendor has shipped a CLI --- and what that absence costs their developer ecosystems.

For a deeper dive into APS authentication specifically, see our standalone Authentication Chaos article.

This article is part of the “Cross-Platform Pain” series, documenting the patterns that repeat across every major CAD/PLM vendor and explaining why CLI tooling is the answer.