In my opinion, API security is counter intuitive to most teams, because they look at APIs as an agnostic, "backbone thing", that you build your apps on top of, instead of a component of actual applications. Also, API design is really hard to make a team work discipline, so one person ends up making a lot of decisions which will affect the application for its entire lifetime.
In fact, a lot of use cases demand you to look at APIs as the business layer, where decisions are made - and that's certainly the truth for Single Page Apps (SPAs) in combination with Oauth2/OIDC. Because of that, and especially for access controls, core controls must be decided on early in the API design stage, or the team will need to roll back a lot of the logic of their application. Despite all this, versioning of APIs makes it easier to make mistakes - but then versioning makes it harder to document.
Anyways, my strategy is to inject myself into the requirements and design phase, so that at least ID, authN, authZ and access controls are aligned with the core product features. In my experience, it's authZ and AC where I've failed the most.
