I am trying to use the GraphAPI using the official nuget library (https://github.com/microsoftgraph/msgraph-sdk-dotnet). However, the authentication process is not trivial and not very well documented.
I am in a CSP partner in a machine-to-machine scenario, so there is no UI application with a redirect url where a user manually enter it's credentials to consent access. But it seems to be the unique scenario well documented or available in the samples I found... Even the official CSP documentation is not clear (https://developer.microsoft.com/en-us/graph/docs/concepts/auth_cloudsolutionprovider).
I previously used many other APIs in production (and TIP environment) as a CSP like MSOL, CrestAPI and AzureGraph, so all the configuration and registration of the application is not a problem.
Is it possible to use MSAL as a CSP in a machine-to-machine scenario? Is there any documentation or sample available for my use case?
UPDATE
I think I am on the good path.
First, I had to register my app on apps.dev.microsoft.com. My apps were previously registered on portal.azure.com. Looks like AzureAD and Graph had different requirements related to where applications must be registered.
Second, I use the sample here: https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2 .
Third, I am able to call the Graph API when I provide my CSP TenantId. However, when I try to call the Graph API using the TenantId of one of the tenant I manage, I got a:
{ "error": {
"code": "Authorization_IdentityNotFound",
"message": "The identity of the calling application could not be established.",
"innerError": {
"request-id": "7cab3137-b3e7-4622-9123-e47f2c018c56",
"date": "2017-09-04T14:48:34"
} } }
(I cannot have the consent page in my use case so I tried to pre-consent my app for all consumers using: https://developer.microsoft.com/en-us/graph/docs/concepts/auth_cloudsolutionprovider)
You can use MSAL to perform the auth required for the Graph SDK. There are some code snippets of using the .NET Graph SDK with the MSAL, but your best bet is the Connect Sample that shows this in a working app.
For a complete guided sample of how to use MSAL and what the library does, checkout the MSAL .NET Desktop Sample.
Related
I have added a non-renewable subscription for one of my projects. We also started implementing the Google play developer API to get the subscription latest status from the Play Store. For that we have done the below steps as per this blog:
Linked the developer account to a new Google Cloud Project.
Enabled the Google Play Developer API for the Google Cloud Project.
Created a service account and created a key for the service account.
I have below clarifications related to this implementation:
I tried to Grant Access for the following permissions: But the corresponding checkmark is not clickable.
View financial data, orders, and cancellation survey responses
Manage orders and subscriptions
The 3rd step as per the blog is to Authorize an API key, but I didn't get a clear idea of that.
We are going to implement this API on the back end side as a corn job, do we need to generate a JWT token for accessing this API? Is this possible to call without a Token? I found 2 types of implementations from this blog, which one is easy and secure?
"Your application can complete these tasks either by using the Google APIs client library for your language or by directly interacting with the OAuth 2.0 system using HTTP."
From where we get the get API path and other details. I found a similar get API from AppStore like this. Is the play store providing a similar kind of get API?
We need the latest purchase status API and for that what parameters do we need to pass?
I write backend ASP .NET Core API and I need to read user Google Fit data.
I created an Android app that gets the server auth code and sends it to backend. As far as I understand, I need to get user token and then use it to access Google Fit. I tried to find libraries for it and failed. I also tried to get user token using Postman and got the following error:
{
"error": "invalid_grant",
"error_description": "Bad Request"
}
Am I doing something wrong?
You may refer with this thread: Using google fit api from a backend server.
To access from a back end server you will need to use the Rest API's There is documentation at developers.google.com/fit. You should be aware that the Google servers and the Android device are synced irregularly so data on the device may not be visible for hours or even days.
You may also check this link on how to read user's Google Fit data via REST API.
There is a mechanism for Android apps to obtain offline access for web back-ends highlighted in the CrossClientAuth guide from your question. With offline access, you can theoretically serve or store that data in any way that the user has consented to. Any access controls of that data to another person is something that you'd have to handle on your own.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
In working with the .NET client library we found that the Email Settings API was not available in it or any of the other client libraries. After communicating with the developers of the .NET library on how the library is generated we noticed that the Email Settings API is not listed in the API discovery service as part of the Admin SDK. The .NET client library relies on the discovery document as does the PHP client. Both the Directory API and the Reports API are.
I noticed that in the documentation for the Email Settings API that calls are still made to apps-apis.google.com:
https://apps-apis.google.com/a/feeds/emailsettings/2.0/
rather than to www.googleapis.com like the other Admin SDK APIs do:
https://www.googleapis.com/admin/directory/v1/
https://www.googleapis.com/groups/v1/groups/
https://www.googleapis.com/admin/reports/
I'm guessing that this is the underlying reason for why this particular API is not included. Is there a timetable for getting the Email Settings API moved to the googleapis service?
There are two types of Google APIs. Gdata APIs and discovery APIs.
The Gdata APIs are old APIs a lot of them have actually been shut down. The client libraries for them to my knowledge where not auto generated.
if you check the documentation for the email settings api there is some sample code for .net.
using Google.GData.Apps.GoogleMailSettings;
The key here is that its a Gdata, its a Gdata api. Which means that like you said its not supported by the current Google .net client library which only supports discovery APIs.
After doing some searching in the code for the Gdata client library. Yes it exists but it hasn't been developed on in ages. There is some code in there for Google email settings There should be a nuget package for it but I have not been able to find it.
The only thing that i have cound that might lead us to the corect nuget package is this
Install-Package Google.GData.Apps
I don't have an admin account so I cant help you test it. However I can probably give you some hints on getting it working. You should be able to track me down from my stack profile if you need help or just post another question on stack. I should spot it.
I am trying to write a custom authentication module for the Remote Desktop Gateway API. However there is no example code of how to use it on the MSDN. I also have been looking around on the net for any kind of tutorial for writing a custom authentication module, but have found none.
I have found a few high level overviews of how RD Gateway works and how to set it up, and I can get the system as a whole working using Active Directory. However, I need to replace the AD login with a custom authentication module (the reason for the API), but I have not seen a single tutorial or working example code that implements the API.
Can anyone provide some working example code that uses the RD Gateway API? I have a strong feeling that I will not find any tutorials, but just seeing someone else's example code would help immensely.
Language does not matter, but as I have learned from my other question about this API it would be better if the solution was native instead of managed, but a managed solution is fine too.
Sample code can be found here -- http://code.msdn.microsoft.com/Remote-Desktop-Gateway-517d6273
I ended up not going with the custom authentication module route, we just made a new domain and added users to that new domain instead.
The closest I ever found in the way of examples was this MSDN archive titled "Remote Desktop Services Developer Resources".
There is a document named "Using the Pluggable Authentication and Authorization (PAA) Framework for RD Gateway.docx" that has some information, but no example code. You can also check the "Resource Publishing and Connection Brokering" release and it does have some example code of the other RDS modules.