I tried get/set the outlook rules using messagerules, the Microsoft Graph API call. It's working for my mailbox without any problem. When i tried doing for other user mailboxes it's failing with error
"code: ErrorAccessDenied", "message:Access is denied. Check
credentials and try again".
I set delegated permissions for the app, passed correct credentials, still it's failing. How to investigate and fix this issue? Any guidance would be of help.
For your scenario, you should use application permission instead of delegated permission, as it won't work for you.
Let me explain a bit. Some apps call Microsoft Graph using their own
identity and not on behalf of a user. They can be background services
or daemon apps that run on a server without the presence of a
signed-in user. These apps make use of OAuth 2.0 client credentials
grant flow to authenticate and are configured with application
permissions, which enable such apps to access all mailboxes in a
organization on Exchange Online.
The related documentation/steps available # link (yes, you can test this via POSTMAN too - detailed steps are given in the documentation itself) as well
You tested it out, confirmed the steps working for you!!
Related
I'm trying to get some data from a user (searchconsole):
the user first grants permission on a website.
Then, the idea is to use that permission and retrieve the data with a python program that'll run on a different server.
What is the easiest/safest way to achieve that?
Should I use the same token for both servers?
or is there a solution using the service account impersonation? (I'm stuck on that one)
use the permission on the web server to add the service account as a searchconsole user?
I tried to move the token from one server to another manually, and it works, but it seems suboptimal to use the same token for both servers.
I also read the doc and all examples I could find, but didn't find my case even though it seems basic.
Should I use the same token for both servers?
Im not 100% sure what you mean by token, you can and probably should just store the refresh token from the user and then you can access their data when ever you need to. This is really how Oauth2 is supposed to work and maybe you could find a way of storing it in a database that both your fount end and backend can access.
or is there a solution using the service account impersonation? (I'm stuck on that one)
Service accounts should really only be used if you the developer control the account you are trying to connect to. or if you are a google workspace admin and want to control the data of everyone on your domain. impersonation can only be configured via google workspace and can only be configured to control users on the same domain. So standard google gmail users would be out.
In the case of the webmaster tools api im not sure by checking the documentation that this api even supports service accounts
use the permission on the web server to add the service account as a searchconsole user?
I did just check my personal web master tools account and it appears that i have at some point in the past added a service account as a user on my account.
For a service account to have access to an account it must be pre authorized. This is done as you can see by adding a user to your account. I cant remember how long ago I tested this from what i remember it did not work as the user needed to accept the authorization and there was no way to do that with a service account.
I want to use azure active directory as my authentication provider for my Spring boot application. Which seems to be quite easy as long as you've got either admin rights yourself or you know someone with admin rights who can give you permission for the tickbox "Directory.AccessAsUser.All". Unfortunatly I dont have that. I know due to other successful projetcs that azure itself gives the oppertunity to still act as an authentication provider even without given any permission to the API Call permission section.
When I start the Server and go on localhost:8080/home whilst tracking my network traffic I can see in the Autherization file the following scope: openid profile https://graph.microsoft.com/User.Read https://graph.microsoft.com/Directory.AccessAsUser.All
So My Idea of Handling this is to reducing the scope of the Authorization request spring is asking for, to meet the authorization scope which I allowed in azure. Which is all of them but the last one as mentioned before.
I tried to configure the scope in my application.propertie with the following: spring.security.oauth2.client.registration.azure.scope=openid
So what happens is after im trying to access my application online im redirected to the mircosoft login page. After putting in my details im getting this:
In order to be able to access resources in your organization, requires authorization that only an administrator can grant. Ask
an administrator to grant permission for this app so that you can use
the app.
Has anyone an Idea of how to handle this?
I'd be greatfull for any help!
I think you can only log in as an administrator, because you are using the SDK provided by Microsoft when you log in, so you cannot customize the scope of permissions in application.propertie.
When you log in to the application, it will require you to consent to all permissions. If you just log in as a user, you cannot consent to all permissions. So, at least in the login module, I think it cannot meet your requirements.
Usually we can customize the scope of permissions only when requesting an access token. For example, if you only need to read user permissions, you can set: scope: https://graph.microsoft.com/User.Read .
Login sample.
Ok, I found the Problem. In my application.property I had this line of code azure.activedirectory.user-group.allowed-groups=. That was reponsible for the bigger scope. After deleting it everything worked fine.
We have an application hosted in GCP which uses GSuite APIs to sync users from GSuite to our application and visa-versa using Service Account. It used to work well until recently some of our customers started facing issues.
We started getting
401 unauthorized. "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There as been no change in our application and neither in the list of permissions granted. Following are the list of api access granted :-
https://apps-apis.google.com/a/feeds/domain,
https://www.googleapis.com/auth/activity,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.orgunit,
https://www.googleapis.com/auth/admin.directory.user,**
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/drive,
https://www.googleapis.com/auth/drive.appdata,
https://www.googleapis.com/auth/drive.file,
https://www.googleapis.com/auth/drive.metadata,
https://www.googleapis.com/auth/drive.metadata.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement,
https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly,
https://www.googleapis.com/auth/admin.directory.device.chromeos,
https://www.googleapis.com/auth/drive.apps.readonly,
https://www.googleapis.com/auth/drive.photos.readonly,
https://www.googleapis.com/auth/drive.scripts
The affected GSuite domains were working perfectly until yesterday. Also there are some domains which still work without any problem.
Can somebody please suggest what could the problem be. Is there any change in the APIs recently? Any help will be much appreciated.
"Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There are several ways to authenticate to Google.
web based applications
native applications
mobile applications
and service accounts
The clients you create for these types is different as is the code to use them. The message you are seeing above means that the code you are using does not match the type of client you have created.
Make sure your code is designed for use with service accounts and make sure that the credentials file you have downloaded from google developer console is in fact credentials for a service accounts.
Why it worked previously and suddenly stopped i cant tell you this is an error you will always get if your code does not match your credential type.
The last option would be to double check that all of those apis are enabled in the Google developer console for your service account project.
I'm faced with a difficult scenario regarding OAuth 2 authentication and Google's Calendar API.
I am attempting to write a PHP script which processes my personal calendar data after being triggered by a POST call from an external source. However, I am having trouble granting the script access to my account. Since the script runs entirely in the background, there is never an opportunity for me to enter the authorization code which is required for PHP command line tools making Google API requests.
I have looked into Service Accounts, which grant access to personal data without individual approval, but unfortunately this is only available to G Suite users, which I am not.
I have also attempted to run my script manually, enter the code to authenticate, then run it from my external source. This doesn't work either, because the authorization codes are apparently only good for the same mode of access where it was entered, and the response to the external source still shows as asking for the code.
Lastly, please note that responding with the authorization code from the external source is not an option. Which I can activate the trigger, I cannot change how it works or the data it passes.
TL;DR: How do I grant a PHP script (which runs only in the background) access to my personal Google Calendar data?
Thanks in advance!
Articulating this question actually helped me better formulate my Google searches, and I found the answer!
I'll leave this question/answer here so somebody can hopefully benefit from it -
Turns out that the Service Account is the way to go, but instead of trying to access your account's data via the service account, you need to share the calendars in question with the generated service account email address. Essentially, this makes the service account a "co-owner" of the calendar. Then, you simply make the request to the service account's own information.
Hope this helps!
Background
I have a Web API registered in Azure AD and secured using WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 bearer token). This is a B2B-type scenario where there are no interactive users - the applications calling the API are daemon-like background apps. As such, I don't need any consent experience - I just want trusted applications to be able to call the API, and other applications - even if they present a valid OAuth token - to be denied.
What I've tried
This sample seemed to describe my scenario almost exactly. However, the way it determines if a caller is a trusted app or not is by comparing the clientID presented via a claim by the caller to a hard-coded value. Obviously you could store the list of trusted clientIDs externally instead of hardcoding, but it seems like I should be able to accomplish this via configuration in the AAD portal so that a) I don't have to maintain a list of clientIDs, and b) I don't have to write my own authorization logic.
It seems like I should be able to define a permission for my API, grant that permission to each calling app in AAD (or a one-time admin consent), and then in my API just check for the presence of that permission in the scp claim.
From looking at the portal it seems like this is what Application Permissions are intended for:
I can create a permission just fine via the application manifest. Unfortunately, I can't figure out how to specify that it's an Application Permission, not a Delegated Permission! I tried changing the type from User to Admin as described on MSDN, but that seemed to have no effect.
"oauth2Permissions": [
{
...
"type": "Admin",
...
}
Question
Am I correct that Application Permissions are the best solution for my scenario? If so, how do I configure it? Or, as I fear, is this yet another feature that is On The Roadmap™ but not currently functional?
Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called say 'trusted' in your resource application's (storage broker demo) manifest - it will show up in the Application Permissions drop down there. Then, when you assign that Application Permission to the client app - the access token that the client app will receive using the client credentials OAuth flow will contain a roles claim with value 'trusted'. Other apps in the tenant will also be able to get an access token for your resource app - but they wont have the 'trusted' roles claim. See this blog post for details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Finally, the above way to assign an application permission to a client app only works when both the resource and client application are declared in the same directory - if however these apps are multi-tenant and a customer will install these apps separately - a global admin from customer's directory will need to consent to the client app - which will result in the application permission getting assigned to the instance of client app in the customer's tenant. (my blog post covers this too)
Hope this helps.
ps: if you're stuck - feel free to ping me on the contact page of http://www.dushyantgill.com/blog