In the Google API docs, it is mentioned that the only way to authorize requests is through OAuth2.0.
However I do not need to access user's calendar, I want to create an event in my calendar and add users as Attendee. I need the invites to go out from xyz.com
Since this is an account I'd own, I feel there should be a way to access it though a service account.
I understand the best way to do this is to write a backend function that is called by my website front-end.
There is some help here, but it is not clear.
When I am creating an event with Person A and Person B
This is how it is today -
Request Access to event from Person A
Event gets created in Person A's calendar and Person B is added as attendee
This is how I want it to be -
Event gets created in my calendar (owned by a service account)
Person A and Person B are added to it as attendee
If you have a google workspace account, and this is a google workspace calendar you are trying to access. Then you could use a service account.
using service account authorization will not require any user interaction. However service account will need to be configured for domain wide delegation in your google workspace account by a workspace admin. Tip if you check that link swap out the scopes with the scope for google calendar.
Service accounts will not work with standard gmail user google calendar accounts. If this is the case then you should just use Oauth2 and authorize your app once and store the refresh token. your app can then use the refresh token to access your account at a later date.
You can use a service account but it requires exposing your client_is and client_secret in the front end. Using service account is called client_credentials flow. It is typically used on the backend because it is meant for server to server authentication/authorization. It is safe to use client secret on the backend.
In your case you have to use authorization code flow. It is not that taxing. This means that you have to obtain a token for your service account by logging in as yourself, the owner of the service account. Then you can create the event for yourself (you app really) and invite Person A and B.
Related
We have done one CRM integration where we as an CRM have our own docusign pro account.
We completed the GoLive process successfully and have all required data like Integration key, Account Id, Client Id and Secret Key for App.
Now this CRM integration will be used as an mediator for our clients who will have their own purchased docusign accounts.
So till now we have 2 accounts,
CRM Integration docusign account with GoLive status.
Client account to send their own documents for eSign through our CRM integration.
What we have achieved till now?
We completed the consent flow where we redirect our clients to docusign consent page where they provide consent to our app by login into their docusign account. In this flow we use CRM integration account id in URL which takes our client for consent page. On confirm the client will be redirected back to CRM with auth code attached in redirect URL.
We use this auth code to get access token for this client. We use CRMs account id, Integration App secret key and clients auth code to get the access token. We are successful in this too. We get clients access token. No Issues.
Now when our client is trying to send a document for eSign using the access token received in step 2 above, the docusign throws an error saying INVALID_USER.
I have referred to this post Simillar Issue it kind of approves of what we are trying to achieve but it is failing with error.
Let me try to explain and make sure it's clear.
The IK (Integration Key) is global for the entire environment. By environment I mean either the developer environment, or the production environment. When you went live and completed the process using a production environment - you made your IK available for any account and any user in the production environment.
Now, when you get an access token to make API calls, this token is for a specific userId. The userId can be a member of one ore more accounts as showed in this diagram:
The userId is provided by the user logging in when given the option to consent. So when you doing your consent flow, there's a web browser and user that logs in, that is the userId that consent.
Separately, when you request a token using JWT grant, you provide a userId, that userId is a GUID for a unique user in the system.
This GUID must be for the same exact production user that gave consent. That's first thing to confirm.
Now, if you already have an access token to make API calls, when you make a specific API call, you need to provide an accountID. That's another GUID representing an account, not a user. The userId that was provided to the JWT Grant flow must represent a user that has a membership (it is a member of) in the account for which you provided a GUID (a user can be a member of more than one account). That is the second thing to check.
Lastly, there's a baseURI that is used to make API calls and it can be different for different accounts. You need to also confirm you are using the correct one.
Some of my application's users have access to more than one DocuSign account. My app is designed to be used with a specific DocuSign account.
Can I specify the DocuSign account during login?
No. With DocuSign, a person authenticates themself as a user, not as a user for a specific account.
However, once the person has completed authentication, your software should use the /oauth/userinfo API call to learn which accounts the user has access to. This API call is also used to learn the user's name and email.
The /oauth/userinfo results will include an array of the accounts that the user is a member of (has access to). The array includes:
the account guid
the account name
the base URL for API calls to the account
whether the account is the user's default account or not
If your application is designed to work with a specific DocuSign account, then your software should check that the user has access to that account and give a clear error message if there's an issue.
If your application can work with any of a user's accounts, then the best pattern is to:
use the user's default account
enable the user to change which of their accounts your application will use
Notes
The /oauth/userinfo API call is available from the DocuSign OAuth service providers:
https://account.docusign.com (production)
https://account-d.docusign.com (development)
The /oauth/userinfo API supports CORS, so it can be used directly from browser-based apps
I saw a post today on linkedIN to say Azure B2B now accepts Google IDs (e.g. people with a Gmail account)
It said this is achieved via Federation, (using google as the identity provider)
As far as I am aware you have been able to do this for a while (or was that because it was in public preview), whereby someone could enter their gmail account but in the background (after the simple on boarding process was completed) this gmail account is linked to a place holder Azure AD account (represented by a GUID).
So in the announcement of Azure AD now accepts google IDs, is this the case where a preview service is now main stream ? or is this something new?
My main question is below
As far as I understand federation (please correct me if I am wrong) although your own Identity provider together with your own STS (secure token service, which is trusted by the replying party) provides you with a token (signed SAML/JWT) with is then presented to the replying parties STS (which then creates is own token from the information in the token you provided), you still need an instance of an object (user/group etc) in the Replaying parties system to check if said instance is allowed access to a resource based on the token (looking at the ACL on the resource and the information in the token). So although the replying party does not need to maintain the users password to authenticate them (done by the trusted Identity Provider) an instance of an object still needs to be created/exists on the Relaying Party system (to match the token information e.g. group membership for example) to the ACL on the actual object trying to be accessed
is the above correct?
Thanks very much
A User is always created in Azure AD, as it is in this case as well.
This applies to users created in Azure AD, synced from on-prem AD, invited from other AAD tenants, personal MS accounts, and now Gmail accounts.
Before Google B2B, if you invited a Gmail user, a personal Microsoft account would be created for them in the background, which would then be added as a Guest in the AAD tenant.
Now if you enable Google B2B, when you invite a Gmail user, they'll log in on the Google login page instead of the AAD login page.
So now instead of creating an MS account invisibly, the Google account itself is added as a Guest User, and AAD relies on Google to authenticate the user.
I am creating a Node JS (Express) web app that will display a user's Google Calendar events, once they have logged in.
There will be multiple users, with data such as name and email address stored in a database.
Once a user has logged in, how can I retrieve a user's Google Calendar events associated to them without requiring any additional user input?
I have implemented Google's quick start sample here https://developers.google.com/google-apps/calendar/quickstart/nodejs
However this provides only access to a single authenticated user (authenticated via a terminal authentication process), with no opportunity to request a calendar of another user.
-
Question
How can I authenticate multiple users via a signup page (rather than using the nodeJS terminal) and access these google calendar events later via the data stored in a database? (Server side, with no interaction required )
Thanks
You can try to use Domain Wide Delegation in the Service Account. It is stated here that:
If you have a Google Apps domain—if you use Google Apps for Work, for
example—an administrator of the Google Apps domain can authorize an
application to access user data on behalf of users in the Google Apps
domain. For example, an application that uses the Google Calendar API
to add events to the calendars of all users in a Google Apps domain
would use a service account to access the Google Calendar API on
behalf of users. Authorizing a service account to access data on
behalf of users in a domain is sometimes referred to as "delegating
domain-wide authority" to a service account.
Just remember that you need a service account here to enable the domain wide authority. For more information, just read this link. It also discussed here on how to create service account.
I've developed a feature on my web-site that allow to log-in using Azure.
So users in my web-site can sign-in using:
Azure (OAuth2). We're using a multi-tenant app. We're just using the application to log in users. So we don't really use the Access-Token to make requests. We just use the access-token to obtain the user email (decoding it with JWT).
Their own email-password they can set on my site.
This creates a problem:
Imagine an person that starts working in a company. The IT team give him an email that belongs to their azure account (with their account domain). This team also have an account on my site (configured with the same domains they use on Azure). So this user will try to log in my site using his credentials. We'll create his profile on their company account (due to the email domain). He sets his password. Sometimes he use Azure to log-in and sometimes he use his email-password to log-in.
The next month and, this person get fired. The IT team delete him from Azure. Although, the IT team forget about deleting him also on my site. So this user has permissions to sign-in with his email-password credentials and still be able to see private information (he can even delete private files).
I would like to know if there is a way to sync my app with every Directory that is using it. So I would be able to receive user action notifications (like user deletions). It would be great to receive a call to an endpoint with information about users important actions. This way we'll be able to delete the user also from our platform. So the company can forget about deleting an user on my site without having the stolen-information problem.
PS: I've seen you have a logout sync using SAML, but I wonder if we would be able to receive other kind of notifications, because we don't want to log-out the user when this logs-out from Azure.
If you have permission from the ex-user tenant administrator to access their directory, you can check if the user is listed or not by using Microsoft Graph API
I've been talking with microsoft support and there is no way of having microsoft calling our endpoint to receive some notifications.
So the only solution is ask for admin permission or, having the refresh_token from Oauth2, check the user still appears on Graph (https://graph.microsoft.com/v1.0/me).