Sign in a user with managed identity instead of secret

Question

I would like to be able to sign in users to my web application using a managed identity to exchange the authorization code for the access token instead of supplying a client id and secret. My aim is to make the deployed web application entirely secretless - which works when using Managed Identity to access downstream services as an application, but I'd like to also make the process of following the OpenIDConnect flow secretless as well. This requires a client secret for the application to exchange the authorization code for the user's access token and id token, and I was hoping that Managed Identity could transparently supply this secret too.

My understanding is that managed identity provides a backchannel in the Azure internal network called the Instance Metadata Service which effectively proxies into AAD using a platform-managed certificate as the secret, and returns the access token. Clients which are aware of the IMDS can transparently make this call to prefetch the access token before making authenticated requests. This means we don't have to provide a client secret ourselves in the client_credentials grant.

Is it possible to provide the client secret in the same way for the authorization_code grant, so that I can sign in users without providing a secret? I don't see any particular reason why IMDS could proxy one grant of an oauth token request and not another. I'd be prepared to write some "glue" code to do this if it is not provided by a supported library.

In other words - to get an access code through client credentials:

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.azure.com%2F' -H Metadata:true -s

Is there any reason I couldn't equivalently do:

curl --request POST 'http://169.254.169.254/metadata/identity/oauth2/token -s -d "{ \"code\" : the authorization code, \"redirect_uri\": whatever, \"grant_type\" : \"authorization_code\" }"

notably excluding the client secret, and letting the IMDS work it out like it does for client credentials?

edit: I had a misunderstanding here regarding the point in the auth&auth flow where secrets are required. They are not required to sign in users but they are required to get an access token on behalf of a user. My scenario had this happening immediately on login, leading to my confusion. It doesn't really change the crux of the question, which is whether I can use Managed Identity instead of a secre to request an access token.

Answer 1

I don't think this will be possible. I have fixated on the idea of the secret for the authorization code redemption step, but not considered that the Managed Identity is fundamentally not an App Registration, and has nowhere to define for example redirect URIs. AD won't know what to do with the redirected login request in the first place. The client ID passed in the initial redirect won't represent an application that AD knows about.