[sandeepkd]

I am curious about the use case to impersonate a user in S2S call here. In regular scenarios the caller service usually have enough privileges that it can pass the user as a header/parameter. An alternative could be OAuth2 flow with password grant type which already exists.

[cyberax]

Plenty of cases. For example, I have an AI service that runs some expensive operations, for example, creates a video with interpretive dance for a given email.

In the normal case, the app running on the device just makes a request to that service, and gets the result back. The service does all the accounting for the request quotas, etc.

Now I want to run the same process for the user's emails in advance, from a service that runs on my server. You can't do this easily with existing S2S auth providers.

[sandeepkd]

Thanks for the example, if I get the use case correctly then its about being able to exectue the operation on behalf of the user when the user is not around. This is what the OAuth2 (authorization) is designed for, the user consents giving the access token to the client app which can interact with the resource servers on behalf of the user. In this case the service running on your server would be the client app and the AI service has the burden to support OAuth2 functionality and API's. It does requires explicit user in the loop for the initial handshake.

However it seems like you are looking at the possibility of not even having the user in initial handshake to exchange/get the access token. Rather you are hoping that its a S2S call to get the token in the context of a user. I am treating this as more of an Assume user scenario and in my mind assuming the user context for debugging and service role is more day to day use case from what I have seen from security perspective. Or read only operations on behalf of user can be another bucket, mutations on behalf of user without users consent is something that sounds tricky for any external service