SAML assumes a relatively equal burden for the IdP & SP, e.g. both are assembling XML messages and may be signing those messages.
OAuth 1.0a, with its multiple tokens and client crypto requirements, likewise placed on the client a relatively high burden.
TLS can work in a symmetrical mode, one where both client & server are authenticated (and share the associated burden relatively evenly) and another where the client gets off easily (but doesnt get authenticated).
OAuth 2.0, and so OpenID Connect, was designed to move most of the complexity off the client. Being an OAuth 2.0 or OIDC client is pretty simple - assemble some HTTP messages, send them to AS via browser, keep track of some tokens, and add those tokens as headers on API calls.
So, for a constrained thing, OAuth 2.0 and OIDC make more sense than SAML (like I need to say that).
When you pair OAuth 2.0 with server-only authentication TLS (or DTLS?), you get
- client authentication (via OAuth 2.0)
- server authentication (via TLS)
- data confidentiality (via TLS)
- data integrity (via TLS)
and, critically, keep most of the complexity off the thing and instead on the server or gateway that is likely more capable of bearing the burden.
Client-authn TLS provides all of the above security characteristics, but with a different distribution of complexity.