> In the AD world, allowing remote code execution is not a bug, it's a feature.

This is the assertion that I think you have failed to prove. RDP and WinRM are just remote access protocols, like SSH or what have you. AD doesn't have to be involved in their use, so I'm not sure how "RDP allows you to log into a server remotely" is AD's problem. Or even a problem at all, since that's what its meant to do.

> A direct competitor of AD is oauth,

It really isn't. OAuth is for authorizing third parties access to client resources, not for authentication. By the time you're getting access tokens with OAuth, you've already authenticated with your identity provider. Perhaps you're referring to OpenID Connect, which is built on OAuth 2.0? In any case, AD and OAuth/OIDC don't really compete with each other. AD is intended to be used on internal enterprise networks to simplify authentication and authorization across a fleet of machines, and OAuth/OIDC have a much more pronounced focus on web.

> which does not allow people to execute code on the issuer

I'm not sure what this means. When you say issuer, are you referring to the auth server that issues ID tokens? What if I'm hosting my IDP in AWS and use an OIDC integration to access my AWS admin console and remotely log-in to my IDP server? Am I not then using it to execute code on my auth server?

"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;