PASETO is a bit of an odd duck, and isn't really an answer to the OIDC vs. SAML question. OIDC relies on JWT in the same way that SAML relies on DSIG, but there's a whole authentication protocol build around it. You would probably not be better off replacing an OIDC implementation with a hand-rolled authentication protocol based on PASETO.
The big problem here is that none of this matters. People do abuse OIDC as a general-purpose token for individual applications, but almost nobody does that with SAML. The point of these schemes is to federate authentication. In other words: it only matters what Okta and Google will agree to do. Your options are OIDC or SAML.
If you had to pick between the two, I guess you should pick OIDC, and think about what Ryan Sleevi said downthread about certificate verification; you'll want some kind of pinning scheme (pinning is a mess in client-server situations, but still sane in server-server applications; in fact, server-server pinning long predates browser public key pinning).
If you're not federating authentication, I don't think you should use JSON tokens of any sort.
The big problem here is that none of this matters. People do abuse OIDC as a general-purpose token for individual applications, but almost nobody does that with SAML. The point of these schemes is to federate authentication. In other words: it only matters what Okta and Google will agree to do. Your options are OIDC or SAML.
If you had to pick between the two, I guess you should pick OIDC, and think about what Ryan Sleevi said downthread about certificate verification; you'll want some kind of pinning scheme (pinning is a mess in client-server situations, but still sane in server-server applications; in fact, server-server pinning long predates browser public key pinning).
If you're not federating authentication, I don't think you should use JSON tokens of any sort.