"This is the assertion that I think .." - you are showing bad faith;

"OAuth is for authorizing third parties access to client resources, not for authentication" - just like AD, oauth is used for authentication and authorization; See the fields sub, scope, audience etc;

"OAuth/OIDC have a much more pronounced focus on web" - of course, we do not use "web" inside internal enterprise networks;

"When you say issuer" - issuer is a keyword, not a random word; But again: you know it;

"Am I not then using it to execute code on my auth server" : can you execute any kind of code on AWS' IAM servers (any server will do) ? Please share some details;

> you are showing bad faith

No, I'm not. You haven't proven it.

> just like AD, oauth is used for authentication and authorization

In a sort of roundabout way, but in those cases what the relying party is accessing are the user's identifying details.

> of course, we do not use "web" inside internal enterprise networks

That's not really what I mean. I would never expose an AD domain to the internet, that's not what it's for.

> can you execute any kind of code on AWS' IAM servers

That's not what I was saying, I was saying it in the context of a self-hosted identity provider. If all you've meant by this entire exchange is that OAuth means you don't have to worry about security because you've outsourced it to someone else, then I've really wasted my time.