We are looking for a way to retrieve the JWT token specific to the current logged in user of Dynamics 365 CE. This is required for one of our integration to pass the JWT to the legacy system using APIM & logic app a middle layer. Below is the entire flow of the integration for which we need this.
CE user will call APIM url(which masks the logic app of http trigger) using some action in the form.
I have enabled the oauth2.0 in the APIM settings and enabled the validate jwt policy.
In CE JavaScript code while calling the APIM URL , we are sending the jwt (that we received using the client id & secret configured in our AAD). This is authenticating the validate jwt policy and oauth 2.0 setting.
The same jwt token we need to pass to the logic app and subsequently to the legacy API using an HTTP action.
Now, we are looking for a way to send the jwt token of the logged in user in CE to the APIM url rather than the one generated using the client id & secret.
Please let us know if this is achievable or we need to change our design.
The whole discussion with customer started about securing the data access in the legacy system. If we use the client id & secret jwt, it is tied to one permanent service account(with system admin role) in CE.
We want to avoid that and retrieve the data from legacy system to which the CE logged user might have access to as per the AAD permission & roles. Please give your suggestions here.
As shown by many samples I have two AAD application registrations, one for my javascript-based front end, and one for my JSON-only web APIs.
If I fully trust my client AAD application, why does AAD require me to create a second AAD application for my web APIs?
For example, assuming I add specific roles to my client AAD application, if client signs in with AAD and gets an id token and access token containing my roles, it only needs to send the access token to my APIs. The API only needs to crack the JWT, validate the audience, issuer, tenant, roles permissions, and signature. In this world, no client secret is needed in the web APIs, a second AAD application registration not needed, and still no call to AAD from my APIs. Unfortunately, without two AAD applications, I cannot figure out a way to have AAD include roles into my access token.
If I didn't fully trust the issuer from mucking with claims, I can see why I would need two AAD applications and a client secret. But since I do trust my AAD application and the signature of the JWT, why the extra complexity? Or maybe there is a way to do this that I haven't found?
Thanks!
Responding to Marc here because just not enough characters in the comments field -- The sample you referenced is an excellent sample, specifically the JavaScript one calling the Web API. It is what I am doing right now in fact. However, the problem is that Web API in the sample is open to anybody who has authenticated on the tenant. I need to secure the Web API down to certain individuals in the tenant, and simply checking the client/app id is not sufficient as anybody who can create an AAD app can fake it.
So what I need to do is have roles added to the the access token so I know that my application authenticated the user, and that user has been granted the required roles. For example, here is a Microsoft sample. And even here a Microsoft video walking through the process.
If I don't have two AAD applications w/client secret, the roles claims is never provided in the access token. It is always provided in the id token, but not the access token.
I feel like I am missing something obvious here. If AAD would just put the roles I requested into the JWT when I authenticated against it, and I validated its signature, audience, issuer, and roles, I wouldn't need any of this extra complexity?
Ah, I think I understand where you are going: you would like to control which users can access an API, no matter what client app they are using to access the API with. That's a function of the API - you cannot control that through AAD. In AAD you can control which users can access which applications (UI) using either user access restrictions (enterprise tab) or role-based access. However, access to an API is controlled in AAD at the calling application level via scopes. APIs are never accessed directly by users but only by other apps so controlling access permissions at user level would cause admin havoc. So, you can control what permissions a user has in the app they are using and you can control what permissions that application (client) has in other applications (APIs, resource servers) it is using.
In other words: role is about user access to UI, scope is about one apps' access to another.
App secrets provide added security for getting tokens - they have no bearing on what permissions are included in the token.
Can you provide a link showing that two apps are needed? That should only be the case if the API you want to call is not provided by the web app which served the JS to the browser. None of the 'official' samples require you to register two apps (Graph API, used in some of these samples is a separate API and it is already registered). A problem with tokens passed from the browser is that they were acquired by a public client, not using any secrets apart from user creds. Therefore, they are easier to steal and re-use. Your own back-end app may want to use a secret to get its own token (extension grant) to call yet another API using a token that does not reside in a public client.
I'm trying to integrate sales force with my application,I'm using oauth2.0 authorization for getting refresh token.I'm redirecting to salesforce login page.I dnt want to show this page in my app.Is there any way for that.
The key concept behind using the OAuth 2.0 Web Server Authentication Flow or the OAuth 2.0 User-Agent Flow is that the users authentication details only go to Salesforce. Your application doesn't need to handle their username or password. This, combined with the authorization of your app in Salesforce gives the user a greater level of security.
You can't store the username/password details and they can revoke authorization access for the app.
If you don't want to redirect via the Salesforce login page you can use the OAuth 2.0 Username-Password Flow. Here you will handle the username and password (plus potentially the security token). This is less secure from the users perspective, but bypasses the redirect to the Salesforce login page.
Incidentally, there is a dedicated StackExchange site for Salesforce that is a great place to ask these sort of questions.
We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.
I am trying to implement a Google APPs Marketplace application. Some parts of the application are web-based and other parts simply need offline access to users data.
During installation, the Google domain administrator grants access to the data required by the application (e.g Calendar).
For the web-based part of the application, users use OpenID+OAuth, so the application can access the user's data (this works fine).
Questions:
What should be the best practice for the offline part to gain access to users data ?
Do I have to store a persistent access token for EACH user in the domain ?
Can I avoid the need for each user to grant access to their data (after domain administrator has already done this at the domain level) ?
Is there a way to utilize OpenId from a background application ?
Since Sean M in fact answered you to the question no. 4 with his comment, I will handle other three:
You can use 2-legged oAuth. Using 2-legged oAuth, application can access services and data that were granted to it during installation process (for example Read/Write access to Calendar) without any additional approval from user.
In 2-legged oAuth there are no tokens. Instead, the app is provided with oAuth key and secret and uses these to access Google services and read/write data.
More reading:
http://code.google.com/intl/cs/googleapps/marketplace/tutorial_java.html#Integrate-OAuth