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
Related
I'm trying to set up a Service Account that can access the GMail API, but for security purposes I want it limited to only a single mailbox (I don't want the development team to have full access to all mailboxes in the organization.)
My understanding of how Google handles service accounts and permissions is limited. I can't seem to find specific details about how this would be set up. I have set up a service account with client ID and secret. And I have associated that with an API client that has the GMail read-only scope. But how does that get associated with a specific mailbox? I do see a setting that allows "domain wide delegation", which seems concerning.
Maybe I'm just not understanding this correctly, but does that mean this service account can now read the contents of all mailboxes in the GSuite account?
How do I make sure this service account is limited to the one mailbox I want it to access?
I think you are talking about user impersonation using the service account. I am afraid that it is not possible to limit the access that the service account can have. The only possible limitations is related to the creations of credentials on the project and things like that, but if a service account has domain wide delegation to do user impersonation, then it is not possible to set up limitations to it.
You can find more info about the possible limitations here https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts
Our application allows users to authenticate via Azure Active Directory using OpenID Connect.
However, some organizations do not allow users to approve applications, and require administrators to approve the application first.
Right now, this means that if a user wants to connect using their work account, we have to first send them to Azure, where they then enter their password, and then are told that our application requires administrator approval. Not a great experience.
Ideally, I would like to give only users whose tenants allow them to approve new applications (or those that already have) the option of logging in via AAD. Is this possible to do through an API call?
Microsoft does not provide such an API for this purpose.
As a workaround, you can quickly check it using auth code flow: Request an authorization code.
Enter their password is necessary. Sign in to this url with customer's credential:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Then they can see if they need admin consent or not.
The essence is the same as the steps you described. But it can save a lot of time.
What is delegated in Msgraph api. Does it mean we can't use it by creating app on Azure Active Directory.
https://learn.microsoft.com/en-us/graph/api/application-post-calls?view=graph-rest-1.0&tabs=http#permissions
I want to use online meeting and call apis without my customers to register teams or microsoft
Delegated permissions are used to call APIs on behalf of a signed-in user.
If an API only supports them, a user will have to sign in to your application so that you can call the API on their behalf.
Refresh tokens allow you to do this for a long time without requiring the user to interact with the app, but those can and do expire.
Another choice might be to use the ROPC flow, but that requires you to use a username and password to get tokens, and that user cannot have MFA enabled for example (one of many cases where ROPC does not work).
There are two primary mechanisms that an application can use to access the Graph. The one is an "Application" approach, where it needs to be given access rights by an administrator, and can then access certain services / endpoints. There's often an "app secret" that is used in conjunction with the application "Id". This is kind of similar in the past to how we would have created a specific 'service' account + password. ROPC is even more similar, and actually -does- require a username + password, but it's not generally recommended.
The other is "delegated", which means that the application can access certain resources that are specific to that user (like their own mailbox for example). In this case, the user themselves might be required to 'approve' the application's right to access the graph on his/her behalf.
Note that BOTH of these options involve the use of an Azure AD Application, but which permission option you can use depends on the specific operation in the Graph that you're interested in calling. As an example, let's say you wanted to access the list of members in a Teams team. This is explained here, where the "permissions" section indicates that either Application or Delegated permissions can be used to do this. In contrast, here is another operation that can ONLY be done with Delegated permissions, and not by a standalone application without a user granting access.
There are various ways to programmatically send e-mail through a Gmail account: service account, OAuth2, API key, and even username/password if the "less secure" setting is enabled.
However, all of these methods require providing some kind of password or token that would allow a user to call any Gmail endpoint on the account. I want to allow access to the endpoint only for sending an email, not for any other Gmail API functionality such as reading email, changing settings, or listing metadata.
The level of granulairty for an API key pictured above is not nearly enough, as it just restricts access to all Gmail APIs.
Is it possible to restrict access to specific endpoints?
You can limit which APIs your project can use, by appropriately selecting them within the "API Library" section. Additionally, depending on the type of account you use, you can apply more restrictions:
Service account
This type of access is meant to be used for server-side applications, in which you/your organisation are the owners of the code and credentials. There is, in fact, no option to limit the scopes that the application can use when authenticating with it.
oAuth2 Client
This type of access is created to be granted to users on demand, from client-facing applications. Using this one, you can limit the scopes it can use by going to Google Developers Console, selecting your project, and navigating to OAuth Consent Screen>Scopes for Google APIs. This will apply to any oAuth client that is declared within your project. In case you need different oAuth clients with different declared scopes, you can consider creating a new project. Note: the scopes restriction will only apply after your application has been verified
We have a bit of a dilemma that we are running into with a couple applications that are trying to read a given users email without user interaction to authorize. The key to this approach is that we want no user interaction, and want to load the client server application with the proper JSON credentials downloaded from the Google Developer Console.
I have this approach working for programs where we create a service account in the Developer Console, and then delegate domain wide authority to that account with the proper scope access. However what we are hoping is that we don't have to delegate domain wide authority, and just read the users email who created this developer console project. I have tried many different types of solutions for this, but always run into the same limitation that I have to grant domain wide access.
What I am wondering is if there is any way to gain access to a single users mailbox using a server to server type approach and not have to grant domain wide access?
I appreciate your help with this issue!
There is no supported authorization flow for what you want to do. You must either use a service account that has been delegated domain-wide authority, or you must use a 3LO flow that involves user consent.
It seems you're looking for OAuth for Server to Server Application. You will also be using a service account. But, granting of domain-wide authority for service accounts is an optional thing. You don't have to enable it if you don't want to.
To support server-to-server interactions, first create a service
account for your project in the Developers Console. If you want to
access user data for users in your Google Apps domain, then delegate
domain-wide access to the service account.
Then, your application prepares to make authorized API calls by using
the service account's credentials to request an access token from the
OAuth 2.0 auth server.
Finally, your application can use the access token to call Google
APIs.