When calling the service.users().settings().forwardingAddresses().create function, I get the error:
"Access restricted to service accounts that have been delegated domain-wide authority"
I've been using credentials via OAuth2 using my personal gmail account. Because of this "domain-wide authority" requirement, does that imply that I can not use the create() function on my personal, non-GSuite account?
You are correct. In this case due to security reasons you can only use this method with service accounts that have been granted with domain wide authority, and this can only be configured in the Google Workspace (G Suite) Admin Console.
This is also described in the official documentation of this method from the Gmail API:
This method is only available to service account clients that have been delegated domain-wide authority.
References:
Method: users.settings.forwardingAddresses.create
Delegate domain-wide authority to your service account
Related
We are looking for an API to add multiple signatures on Gmail accounts. Is it available?
We integrate an API to update the current signature but we need to add multiple signatures now.
Issue:
You are not impersonating an account.
Explanation:
The whole point of granting domain-wide delegation to a service account is to be able to act on behalf of any user in the domain. If you don't impersonate another account in the domain, you are using the service account by itself, and the fact that you've granted domain-wide delegation doesn't have any effect (the service account by itself is not even part of the domain).
More specifically, you have to impersonate the account to which you want to add a signature, and use that to create an alias with a signature or to patch an existing one.
Not sure which language are you using, here you can see examples of impersonation in multiple languages: Preparing to make an authorized API call.
Reference:
Delegating domain-wide authority to the service account
Managing signatures
i'm trying since 3 days to grant admin consent of application permissions in an azure b2c tenant for an enterprise application.
The App is registered in my main-tenant with all its delegated and application type permissions, which are granted tenant-wide. The main-tenant also has an entry in its enterprise applications where i can see the same permissions.
I dont know how to add the app in my side-tenant without publishing it to the MS store. So i simply login my app with a side-tenant-account. (I dont know if its the correct way?)
After the login i have an entry in my enterprise applications of my side-tenant, but without the permissions i need?
Now here is my question: How can i grant the permissions i need for all users in my side-tenant?
I already tried this Url: https://login.microsoftonline.com/{tenantID}/adminconsent?client_id={clientID}&scope=/.default&redirect_uri=xxx
For my main-tenant it works as expected, maybe because it has the application registration, which is missing in my side-tenant.
When i try it with my side-tenant, i'm getting this error:
Acess_denied: AADSTS650054 The application XXXX asked for permissions to access a resource that has been removed or is no longer available. Contact the app vendor.
What is likely happening here is that you have configured your app to request access to at least one API which has no representation in "side-tenant" (the API called "LegacyAPI", for example). That's why the error message mentions the "resource that has been removed or is no longer available".
For consent to succeed, all of the resource services (i.e. the APIs) the app is requesting access to must exist in the tenant where consent is being granted. (A service principal object needs to exist.)
You have two options here:
Grant consent to the missing resource services in "side-tenant" (e.g. via the admin consent URL)
Manually create a service principal for the missing resource service in "side-tenant" (e.g. New-AzureADServicePrincipal -AppId "{resource-app-id}")
Not related to your issue, but related to the admin consent URL:
For what you're trying to do, there are three ways to construct the admin consent URL, one using the older v1 endpoint, and two using the newer (recommended) v2 endpoint. In your admin consent URL, you are using the v1 endpoint, but you are including the scope parameter (which is only used in the v2 endpoint).
v2 (recommended)
For all permissions configured in the app registration, revoke any other permissions that were granted tenant-wide (static):
https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent
?client_id={client-id}
&scope=.default
&redirect_uri={redirect-url}
For the delegated permission User.Read for Microsoft Graph, don't revoke other permissions which were already granted tenant-wide (dynamic, incremental):
https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent
?client_id={client-id}
&scope=https://graph.microsoft.com/User.Read
&redirect_uri={redirect-url}
v1 (supported, not recommended)
For all permissions configured in the app registration, revoke any other permissions that were granted tenant-wide (static):
https://login.microsoftonline.com/{tenant-id}/adminconsent
?client_id={client-id}
&redirect_uri={redirect-url}
Reference: https://learn.microsoft.com/azure/active-directory/develop/v2-admin-consent
I Followed the Active Directory .NET WebAPI onBehalfOf sample.
In the web api created another endpoint to access Intune app protection policy from url
https://graph.microsoft.com/beta/deviceAppManagement/managedAppPolicies,
in azure provided permission to app to access Graph API.
In the call to AquireTokenAsync changed the resource Id to https://graph.microsoft.com/.
This returned the JWT token that contained:
"aud": "https://graph.microsoft.com/",
"scp": "DeviceManagementApps.ReadWrite.All User.Read",
However fetching the endpoint
https://graph.microsoft.com/beta/deviceAppManagement/managedAppPolicies
Returns an HTTP response of 401 Unauthorized.
What is missing?
This generally implies one or both of the following issues:
You need to obtain Admin Consent. The DeviceManagementApps.ReadWrite.All scope requires that an Admin consent to the permissions before a normal user can can authorize the scope.
You're app's registration doesn't have the correct scopes defined in Azure. Make sure your registration is selection scopes for Microsoft Graph and not Azure AD Graph API. These are two distinct APIs and the differences are greater than simply the resource URI.
Also note that the Client Credentials grant (aka Application scope) isn't supported by the Intune APIs. You can only call these endpoints using Delegated permissions (Authorization Code or Implicit grants).
I am trying to perform server-side OAuth so I can use a specific user account in my domain to send emails (hence using GMail API) via my application.
Mine is a purely server-side app and I cannot perform "user consent" via a UI.
I have created a project in Google App Engine and have obtained service account credentials (P12 key).
My code looks like this -
new GoogleCredential.Builder()
.setTransport(httpTransport)
.setJsonFactory(JSON_FACTORY)
.setServiceAccountId(googleEmailerServiceAccountId)
.setServiceAccountPrivateKeyFromP12File(new File(googleEmailerServiceAccountPrivateKeyLocation)).setServiceAccountScopes(Collections.singleton(GmailScopes.GMAIL_COMPOSE))
.setServiceAccountUser("xxx#xxx.com")
.build()
I have delegated domain wide access to the application (for GMAIL COMPOSE scope) via the admin console as per https://developers.google.com/identity/protocols/OAuth2ServiceAccount.
And I still get an Unauthorised 401 when I try to send emails from my app.
Since there is no explicit documentation for the Gmail API that says it allows domain wide delegation, I am guessing it is not allowed for Gmail.
Is there any way of achieving this programatically?
Any idea would be much appreciated.
Thanks!
As far as I know you cant use a service account with Gmail. Service accounts must be pre authorized.
Authorizing Your App with Gmail
All requests to the Gmail API must be authorized by an authenticated
user. Gmail uses the OAuth 2.0 protocol for authenticating a Google
account and authorizing access to user data. You can also use Google+
Sign-in to provide a "sign-in with Google" authentication method for
your app.
Share a Google drive folder with the Service account. Add the service account email as a user on a google drive folder it has access
Share a Google calendar with the service account, just like any other user.
Service accounts don't work on all Google APIs. To my knowledge you cant give another user access to your Gmail so there will be now to pre authorize the service account.
Recommendation / work around / hack
Create a dummy app using the same client id, authenticate it get the refresh token then use the refresh token in your application.
Is it possible to limit my endpoints api to my organization's Google accounts?
P.D.
I do not have access to the Administrator account.
Thanks
You could protect your API method by injecting the User object. Now, when the API Method is invoked, you can check for the User object and get the Email Addresses and Authenticating Domain to perform your check and move ahead in your API Method.