Flowing logged-in user credentials to Web API


  • Hi all,

    I posted this in a Dynamics forum, but was asked to post here.

    Can I flow the logged-in user credentials to a Web API that is running in my customer's tenant in Azure?


    I'm building a Web API in Azure using .Net Core 2.1.  I have a web app that will access this API, and plug-ins from various systems will access it as well -  Dynamics AX, Dynamics CRM, Dynamics 365, etc.  This application will be installed into the tenants of other customers.  So the caller is the plug-in, not the other way around.  The plug-ins will be installed into the customer's instance of the Dynamics systems.

    Right now, the API is secured using Oath2, with a client ID/password - in other words, not using the credentials of the calling user.  That's because I can't get the credentials of the user in an Oath2 form without requiring them to log in again. 

    Note that my team controls the web app and the plug-ins.

    Is there any way, in a plugin like I mentioned above, where I can get the user's credentials in a way that I could pass to the API without requiring another login? 

    I would prefer to use AAD/OpenID because:

    1) I really don't like the idea of a shared secret

    2) we are thinking about allowing our customers to write to the API as well

    3) My customer would like to enforce a 'Named User' licensing model.  Right now, I'm relying on the plug-ins to send me the name of the user.  If we allow #2, the customer could write code that always sends me the same name, bypassing the Named User licensing requirements.

    All of the examples (for every plug-in type) show getting a token by using a shared secret.

    Thanks in advance.

    Thursday, December 6, 2018 11:45 PM

All replies

  • Hi Phillip,

    Your Web API (protected by Azure AD) should be accessible by users from multiple tenants ,so you should register that as a Multi tenant app. This will ensure tokens issued by other Azure AD tenants are also accepted by your API. 

    Example: Web API and web app are protected by tenant A and are registered as multi tenant apps. In the required permissions for the web app we add the web API.

    Scenario A: Accessing the API from Web App

    1) Admin from tenant A tries to access the web app > provides consent for the API and will be able access the API.

    2) Admin from tenant B tries to access the web app > provides consent for the API and the app and will then be able to access the API.

    Check this sample which could help you.

    Scenario B : Plugins accessing the API using user impersonation. Check this thread for some ideas regarding this.

    User from any tenant  will sign in to CRM and if the plugin impersonates the user then you should be able to pass the same token to your API and provide access to it as well.

    Note: Microsoft Graph API is an example for your scenario. It is registered in one tenant by MS and is accessible for users from all Azure tenants.

    Tuesday, December 11, 2018 12:37 PM
  • Thanks for the reply Manoj.  I'm not sure that this is exactly what I need.

    What I don't have is a trust-worthy way to tell the API who I am from the plug-in.  From the plug-in, I can get a JWT token using the 'client credentials' grant, where I provide a client ID and client secret.  The ID and secret can come from an AzureAd App Registration, with a key.  This works right now, but I have to pass the user name in a header to the API so that I know who the user is.

    So the token is for the same user every time - like a 'service account'.  What I'd like to do is create a JWT for the user that's currently using the plug-in - or use one that is already in place, so that the user's claims are there, and I trust who the user is.

    This is the piece that I can't figure out how to do.  I'd like to do this so that I have more confidence that the user is who they say they are.



    Tuesday, December 11, 2018 2:58 PM
  • Hi Phil,

    Let's assume you figure out a way to send the user details to the API. There could be potentially thousands of users who will be using these plugins right ?

    How are you planning to ensure that it's a valid user ?

    If the user details are not present or some random details are coming over to the API, what should be the behavior ? Should the API behave differently or block access ?

    I was thinking of API providing access based on user identity and not the client ID and Secret and suggested making the API multi tenant. 

    Wednesday, December 12, 2018 7:20 AM
  • I want the API to provide access based on user identity too.  That's my whole question.  How do I do this from a plug-in?  If I secure the API via user identity, I have to somehow tell the API, when I access it from a plug-in, that the user is who they say they are.

    If I was using OAuth2, for example, I could flow the token. 

    I have no problem making the API multi-tenant, but I still need a way of passing the user information from the plug-in.  You are suggesting that I find a way to pass user information to the API from the plug-in.  Yes, please! :-)  Any suggestions on how exactly to do that?

    Wednesday, December 12, 2018 2:28 PM
  • I don't have expertise in Dynamics CRM , but I found these articles.

    Dynamics :

    3rd party article :

    Thursday, December 13, 2018 9:51 AM
  • Hi Phillip,

    Just checking in to see if you found the above reply helpful and were able to resolve your issue.

    Wednesday, January 2, 2019 6:28 PM