“Should we use OIDC or OAuth2?” is the question, and it contains the misunderstanding. They answer different questions, and most applications need both.
“Aren’t they the same thing?”
OAuth 2.1 is an authorisation framework. It answers: may this application access this resource, on whose behalf, and within what scope. It was never designed to tell you who the user is. People used it that way anyway, by calling a profile endpoint after the fact and treating the result as proof of identity.
OpenID Connect is a thin layer on top that does the part OAuth2 left out: it issues an ID token, signed, with claims about the authentication event itself — who, when, and how strongly.
“So can I just use the ID token for my API?”
This is the bug. An ID token is a statement to your application about a login that happened. It is not a bearer credential for a resource server, it carries no scope, and its audience is your client rather than your API. Accepting it at an API endpoint means accepting a token that was never meant to be presented there, often with no way to constrain what it permits.
Access tokens exist for that job. They carry scope, they can be short-lived, and they can be revoked without disturbing the user’s session.
“Do I still need PKCE if I have a client secret?”
Under OAuth 2.1 the question is settled for you: PKCE is required for every authorization-code flow, confidential clients included. It binds the code exchange to the client that started it, so an intercepted code is useless without the verifier. A client secret gives some protection already, but the gap reopens the moment someone adds a mobile or single-page client, and PKCE closes it for both. We make it the default rather than an option, so the question becomes whether there is a reviewed reason not to.
“What about SAML, then?”
SAML answers the same question as OIDC — who is this user — for a different generation of applications, with XML assertions instead of JSON tokens. If your enterprise customers ask for it, you need it. That is usually the whole decision, and it is a commercial one rather than a technical one.
The practical answer
Use OIDC to establish who the user is, use OAuth2 access tokens to reach your APIs, keep the two kinds of token separate in your code, and support SAML when a customer requires it. The failure mode worth watching for is a single token travelling everywhere, because that is the point at which identity and authorisation stop being separable.