Which further limitations does SAML have beyond browser SSO, and how can they be worked around?

SAML is awkward for non-web applications (legacy systems, smartphone apps) and for delegation (a protected portal calling a back-end service on the user's behalf); workarounds include service accounts with VPN or SSH tunnels, Kerberos, combining SAML with OAuth 2.0/OIDC, and brokers.

Non-web applications: Web Browser SSO depends on redirects and auto-submitting HTML forms. A native mobile app, a thick client or a mainframe terminal has no natural place to run that flow. (The ECP profile exists for smart clients but is rarely supported.)

Delegation: a portal that has authenticated the user via SAML may need to call an API on the user's behalf. A bearer assertion addressed to the portal (audience restriction) is not meant to be forwarded, and SAML has no widely deployed, simple mechanism to obtain a scoped token for the downstream service.

Workarounds:

• Service accounts plus VPN or SSH tunnels: the portal calls the back end with its own technical identity over a protected channel; simple, but the back end no longer knows the user.
• Kerberos: ticket-based delegation inside a Windows/Active Directory domain.
• OAuth 2.0 / OpenID Connect: tokens designed for APIs and apps, often issued after a SAML login.
• Brokers (intermediaries): a central component that translates between protocols.

Go deeper:

• OASIS: SAML V2.0 Enhanced Client or Proxy Profile — SAML's own answer for non-browser clients.