Grant type=password doesn't work with SN+I when trying to get access token

[ajitbalaga168]

Scenario description:
We have a scenario where we call the Graph APIs using a 3P Torus app to perform some activities on a user tenant. For example, we install a list of users within a tenant, add a few emails and chat messages between the users, and we upload some content into the user's one drive. To perform these actions, we get an access token for the Torus app and then get an access token for the admin user using the grant type=password flow.

Old solution:
Before the security wave, we used the client id and client secret along with the username and password to get the access token. We then use this access token to call Graph API to perform the activities described above.

Current solution:
In the current solution, we use a certificate to get the access token with a client assertion instead of a client secret. This solution requires us to upload the current certificate to the 3P Torus app and the certificate needs to be updated each time it's rotated, causing service outages and is not recommended from a security perspective.

Code for the current solution can be found here.

Desired solution:
Optimally, we would like to use SN+I to pass in the required info with the API call as needed to get the token, without uploading a cert to the app each time it's rotated.

Please help us figure out if we're missing anything in our current solution and what changes we need to make to get to the desired solution. If there is a safer and better alternative to the desired solution, we would be happy to look into it.

[rayluo]

SN+I used to support only AME certs, and it looks like that is still the case. Perhaps you can explore using Managed Identity or have your Torus app federated by Managed Identity. CC @localden who may provide more details on the latter.

[bgavrilMS]

The solution here is to use Managed Identity @ajitbalaga168 - because the best way to deal with certificate rotation is to not deal with certificates at all.

SN/I is only an option of scenarios where Managed Identity cannot be used.

https://review.learn.microsoft.com/en-us/identity/microsoft-identity-platform/federated-identity-credentials?branch=main

[ajitbalaga168]

The authority for our certificates is AME. We are also able to get an access token for the app using the certificate. It fails when we try to get an access token for a given user context (which we provide as username and password with the grant type=password). In this case, MSAL requires that the certificate be uploaded to the app.

Regarding managed identity, we're not able to use it in our current infrastructure. We have partner constraints that only allow us to use SN+I.

[localden]

@ajitbalaga168 because this goes beyond a public discussion on GitHub, can you please start a thread in the internal Stack Overflow and share it with Bogdan and I? That way we can use it as a point of reference for other teams that might encounter your scenario.

[ajitbalaga168]

Created a question on internal stack overflow and tagged both of you on it.