my problem is that I try to collect data from one of the dataverse table from the c# backend code, but without app registration and getting app id (long business process in my company). Is there any way to achieve using something other than official dataverse web api?
I was trying to use httpClient to send GET requests to the dataverse, as well as DataverseClient nuget package and FetchXMLBuilder. I couldn't connect
You do need an authenticated and authorized user to access dataverse via its API's (Any modality)
If you have an account to the dataverse instance you are looking to query data from and are authorized in the system to do so, you can create an interactive login via the Dataverse ServiceClient, or set up the same via MSAL (or similar) library and access the API that way.
Headless connections however do require a Client Application ID and either a Client Secret or Client Certificate to connect.
Related
I am currently building an api along side our external app developers. I have read that the Authorization Flow with PKCE is definitely what we need for this set up however I am looking for some more detailed advice.
Our existing api uses the implicit flow and the app sends credentials + secret etc to the /Token endpoint in the api this then looks up the passed in data and compares with our users table. If that passes an Access Token is returned to the app.
With this new flow I have the following questions.....
Do I have to use Okta Portal/Dashboard and set up the api there?
Do all app users have to be stored in Okta dashboard? We usually manage our own users table where we add users from a custom tool. However I am presuming when using Okta our custom tool would need to call Okta api endpoint and register the user from there and then get and store the users Okta ID in our own table. **Does anyone have an example of how I do this from a C# Wpf application?
Do I then need to request the Redirect URL's from the App developer and set them up as a Native App in Okta dashboard. Presuming I need to give them some set values to hold their end to allow them to call Okta at authorization.
OpenID????? do I need this if so how and where does this get implemented?
I have read through so many tutorials but just havent quite found the exact fit yet.
Many thanks
You will need to access Okta admin console to register a client application. Once done, you can use Okta OIDC API's: https://developer.okta.com/docs/reference/api/oidc/.
You can use Okta SDK's to simplify the development process. Ex: https://github.com/okta/okta-oidc-ios
If Okta is going to be the authorization server, users and their credentials will need to exist in Okta
When you create a native App in Okta admin console, you will need to provide the redirect URI's that will be whitelisted
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. When you create a native application in Okta, will be a OIDC application.
The Company I work with has many clients who uses Google Ads to do marketing for their websites. The company wants to use client's data for Analysis.
I am given a project to integrate Google Ads API using C# to get all the data such as Campaigns etc from Google ads and move it to our system for each client.
I am only given developer token and customerID for Clients.
such as
Customer ID for Client A
Customer ID for Client B
I am bit lost when I went through the google ads API documentation. In the documentation, the OAuth2.0 needs creating in order to use client library which would generate client ID and Client Secret, Refresh token to integrate the API.
My question is. Do I need to create OAuth2.0 for each client or do I need to ask my company to generate Client ID and secret in company's Manager Account or Client that uses Google ads would provide me these?
The following Link I found to create OAuth2.
https://developers.google.com/google-ads/api/docs/oauth/cloud-project
This is what I believe would require in C#
Content can be found at https://developers.google.com/adwords/api/docs/guides/first-api-call#.net_1
Would highly appreciate if any one can help me what actually I need to configure google ads using C#
If your company manager account is a manager for the relevant client accounts, you would just need to authenticate as the manager account using your developer token, client id and secret. This gives access to the Ads data for all clients linked under the manager account.
E.g. calling Google Ads API CustomerService > ListAccessibleCustomers returns a list of customers accessible to the authenticated client.
Further to comments where you say you will be creating a console app:
The link in your question says use a desktop application if:
You're managing all of your Google Ads accounts using a single top
level manager account. You're a first-time user, or want to get
started quickly with the simplest setup. Your app will only
authenticate Google users from one machine.
So using a manager account which links the required client accounts would be required in this case. See OAuth desktop application flow.
If you used a web application, the clients could log in and your app could read and store their refresh token in a database to make future calls to the api for their account.
You only need to create one application in the Google Console and have one Client ID and Client Secret for it.
Using that one set of credentials, you can go through the OAuth flow with each user to get an access token and refresh token for each of them. The access token, along with your Developer Token, will give you access to AdWords APIs for the user that granted it to you.
You need both your Developer Token and your user's Access Token in order to access the AdWords API.
If you're not as familiar with OAuth, you may look at a managed provider like Xkit (where I work). They have step-by-step instructions for accessing the Google AdWords API including how to generate the credentials and how to use them.
I have inherited some code which acts as middleware between our application and MS Dynamics 365.
It currently uses client secret based authentication, however the client secret is stored within a web.config, meaning that anyone who gets the appropriate URL to our app has access to the MS Dynamics org, which is bad...
I have updated the code to use a Certificate instead of a client secret, which makes management/housekeeping easier, but again if anyone gets the url, they have access to the org...
The middleware app code is all C# and uses the Microsoft.Xrm.Tooling namespace (CrmServiceClient) for establishing a connection to MS Dynamics 365.
The application works well, but is just insecure.
Our application is embedded within MS Dynamics as a popup page launched from a Web Resouce (some JavaScript with a window.open) and users have to be logged into MS Dynamics to be able to access this Web Resource.
In Salesforce.com, we use the SessionID to pass to the middleware to establish an API connection, but MS Dynamics doesnt seem to have anything like this available.
The call chain is basically:
MS Dynamics > Embedded page
Embedded Page > middleware app - establishes a MS Dynamics connection using clientid/secret or certificate stored within the Azure App service or Key Vault
Middleware app > our app
Our app > middleware app (to load CRM data) this is really where the security flaw is, if a nefarious user has the url to our app at this point, they effectively have access to MS Dynamics data with no authentication challenge (as the MSD connection is established using clientid/secret stored within the web.config or a certificate, which is stored on the web app)
I dont want to introduce a login screen to our app as it will break the immersion and people will hate it.
Can someone please suggest a better appproach for me?
I am looking at adding custom authentication to my existing Xamarin.Forms app through Azure Mobile Services. Currently, my app authenticates itself against an existing WebAPI but the authentication isn't secure and I don't really want to start trying to create my own secure authentication process for production. I thought that Azure Mobile Services would be a good way of being able to keep the custom authentication side of my app (authentication against a current identity provider isn't an option) however I already have all the storage etc set up in an existing SQL database by sending it to the WebAPI first and then saving details.
I guess my question is: Is it possible to set up Azure Mobile Services with my current WebAPI acting as a kind of middleman? The basic workflow would include my app sending the log in details to the WebAPI, the WebAPI passing these on to Azure Mobile Services for authentication and then returning the response including token to the app after being stored on the WebAPI side.
The reason I thought that Azure Mobile Services would be a good choice was because it also provides support for push notifications as well as the custom authentication side of things.
Thanks.
Take a look at the following for custom authentication: https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/
Short version - yes, it is possible. You create a custom WebAPI that mints a ZUMO token within your Azure Mobile Apps SDK Within that minting process, you can check the users credentials (either a token, remote API or whatever) any way you want.
I am not sure if that is possible. You are trying authenticate through two different application. It might be possible to write the mobile service client login code in your web API app to use authentication from Mobile Service app and get the token back. But then you still have to manage the user sessions between your Xamarin app and web api app, cross origin stuff and etc,
Since mobile service app really is a web api wrapped with some extra functionality, have you considered moving your web api app to mobile service? That might be easier in my opinion.
Yes, this is possible.
In our app the user is able to register and to login with twitter and Facebook but with own email + pw, too.
In wams we sync the social account and "our" account (stored in the db).
Have a look at ClaimsIdentity and Microsoft.WindowsAzure.Mobile.Service.Security IServiceTokenHandler to implement custom authentication and returning a custom token.
Is there a mechanism in Azure AD to have a completely headless authentication? Most likely this would mean (in my mind) that the server running the API would have a perpetual authentication session to Azure.
If the purpose matters... We have a need to expose our thumbnailImage attribute from AD and I just need to make it so that the server doesn't care who requests the image. So basically we will have https://domain.com/api/Image/userid and the api will return an Image object (image/jpeg). I have this functioning internally and now I'm just migrating to Azure.
I found this question... I just want to confirm two things...
Daemon or Server Application to Web API is the method I should be looking at
Using this method will function as I'm expecting... a.k.a. WebAPI can access that attribute and use it like I currently use it while inside our internal domain.
Indeed. Azure AD supports the client credential OAuth flow. Yes, you are looking at the right help topic. The corresponding sample application is here: https://github.com/AzureADSamples/Daemon-DotNet.
If you haven't already, use Azure management portal to register your WebAPI as an application in your Azure AD directory and add a client secret (under the section named 'key' in the 'configure' tab of the 'application'). This key will be used as the client credential.
To configure permissions for your WebAPI to be able to call Graph API using client credential flow token, go to the application tab in the Azure Portal, under Azure AD and in the section titled 'Permissions to other applications', add an 'Application Permission' to 'Windows Azure Active Directory' to 'Read directory data'.
What you refer to as perpetual authentication session is basically your WebAPI caching the access token to Graph, and getting a new access token (using client credential flow) when the current access token is about to expire.
Hope this helps.