Since we can get a user's email address from the Gmail Add-on API, I'm wondering if we need to authenticate users with OAuth before they interact with our external service or whether we can rely on a stored secret to ensure that requests made with the user's email address are actually coming from a user using the Gmail add-on.
Since app scripts run on Google's servers and aren't modifiable by the user, we could just HMAC the request bodies in the requests to our external API with a secret stored in the Code.gs file. This would (maybe?) ensure that it this endpoint was actually being hit by Google and that the person making the request was the owner of the given email address.
For this approach to work though the secret in the code would actually need to stay secret, otherwise anyone could just hit that endpoint with any email address and post data on behalf of other users. So does this approach actually work, or is there another similar solution that might be feasible?
Otherwise we can just implement OAuth, but if there is a simpler approach that's secure then that would be preferable.
Let's say your external API just need an API key(a secret) to authorize users. You can definitely store it using Properties Service .
But the tricky part is that different user might have different API keys. To solve it , we could ask the user to enter the API key in the UI (can't be masked, though).
This is a very simple approach.
However, I would recommend using OAuth , as it is a more cleaner way.
Related
First of all, sorry for my bad English :)
I am building a Gmail addon which integrates file uploading to an external website using their API. The API have an auth endpoint which uses plain authorization flow i.e. takes email and password of a user to authorize and return authorization token. That token is then used in the subsequent call of file uploading process.
My question is, it has been mentioned in gmail addon guide that an app should use oAuth when connecting to a third-party service. However, the related website's API do not have oAuth but use plain authorization flow. If I create a login form with email and password fields using the card service, would that be okay and approved by google to be listed in the addons directory? Creating oAuth on third party service is not in my hands
Thank you!
Q: would that be okay and approved?
My experience is that it is OK to use basic authentication (since a lot of APIs still use basic auth, it would be devastating if the use of API was prohibited), most likely you will be approved. However, if there ever be a version of the API that supports OAuth, please, migrate as soon as possible.
Caveats
You mentioned creating a login form in CardService - please, be aware that there are no "password"-style TextInputs, so all characters will be visible all the time + there isn't, as of yet, any support for input event, so you won't be able to emulate the behaviour easily.
If you are planning on storing the credentials, try to avoid using PropertiesService - it isn't considered a secure storage (though if credentials are to be entered only once, storing the token should be fine).
You will still be asked to implement the authorizationCheckFunction.
I can't figure out how to make a shared Google Apps Script library, that uses OAuth 2.0.
The problem is that the usercallback redirect URL changes, every time I use the library in a different script. However, that means I'd need to add a new app and whitelisted redirect URL to Asana for each spreadsheet I use the script in. I'm using https://github.com/googlesamples/apps-script-oauth2.
Is there a way to always authenticate with the same redirect URL, so that the library I make can be used from any script, without registering a new redirect URL in Asana?
I'm a Developer Advocate here at Asana. If I understand your question correctly, then yes, you'll have to handle the callback separately for each script. For security reasons, we validate that the OAuth app registration registers the same url as an integration actually requests when authenticating. If this weren't true, for instance, it'd be possible to create a malicious script that uses the client_id from a legitimate script but asks for the redirect to go to its own credential-grabbing endpoint. This is fixed if the app that got the client_id on app registration also specifies precisely which endpoint should be the legal endpoint to redirect to. That means each OAuth app needs to have its own unique and consistent redirect URL :(
I suppose you could possibly create a single "router" Google Apps script which would set the state parameter with some user/script pair when hitting Asana's oauth_authorize endpoint and forward the user credentials on to the script that exists behind the router script based on that user/script pair when the response comes back, but it's not super trivial.
One final option would be to use a Personal Access Token to access Asana's API. This one token can be used by an unlimited number of scripts for access. The downside is that this token "looks like you", that is, it takes action on behalf of not a third party user but you yourself - your scripts would be an automated version of the user whose Personal Access Token they use. This can be mitigated to some extent by creating a "bot account" to access our API and giving it access inside of Asana to the projects or teams you want to gather data on. The other downside to this approach is that every script that uses the personal access token will break if you ever revoke the one token, so if that ever happens by either intent or accident, you'll have to update the Personal Access Token information in every script that uses it.
Hopefully this helps you to evaluate the options and choose which one of these options works best for your script.
I'm currently writing an auditing script that is focusing on users' gmails and need access to their message lists. I have admin access and scopes for the AdminSDK, the script will be executed by the admin.
I'm wondering how exactly to do this? I have my domain's userlist via Directory, but I can't use GmailApp with a specific user, only the current user(admin). I was also thinking about assigning a timed Trigger to each of the users and using GmailApp locally, but I can't figure out how to do that either(I don't think this is possible).
One idea that I'm working on is pinging the Gmail API using the admin's credentials via URLFetchApp, but can I get my domain's users information with this method?
What are your thoughts? Any guidance will be appreciated.
I'm currently using GAS on a service account.
While using service account, you can impersonate users in your domain and perform actions on their behalf. For this you will need to perform domain wide delegation of authority in your domain.
Here you can find documentation about domain wide delegation.
Here you can see an example, I know is on Drive but the principle is the same.
Hope this helps.
I need to get the user email when I get document permissions. I have seen this problem here
value attribute for Permissions Resource not populated in responses
but in about service does not appear my email. I need it because I have a service account and my application need know the user email. I want to avoid call to profile service.
Is this possible? from where I can get the user email?
Thanks.
As you rightly say, you will have to make a call to the profile service. In some ways it is better like this, because it separates the concerns of the Drive API and the Profile API, and can use specific scoping to let the user know exactly what they are authorizing your app to do.
Looking at:
https://developers.google.com/drive/v2/reference/permissions#resource
the values attribute which contains the email address value for the ACL is not returned by the API. It's not clear why the value isn't returned, I assume it's a privacy issue but it means Drive SDK can't support document migration (from one Google account to another) use cases where the old Documents List API v3 can:
https://developers.google.com/google-apps/documents-list/#retrieving_the_acl_for_a_document_file_or_collection
for now I'm looking at adding both Drive API and Docs v3 API scopes for my project and just using the Docs API call to retrieve the ACLs but ideally I'd be able to use just Drive API calls. Am I missing anything? Could a special scope be added to Drive API that allows ACL email address retrieval or is there some other way to handle this?
Jay
Thanks for your question Jay and thanks your answer Ali Afshar!
Unfortunately I do not understand how Google believes the following scenario should work without the email address of the users:
In Documents List API v3 you could copy a file A to file B, retrieve the ACL-information of file A (including the users email adresses) and simply add them as ACL to file B.
With Drive API you can retrieve almost the same Permission information, but without the user email address, which is still required to re-share file B to the same users.
As a sidenote: If you use GAS DefaultService DocsList, you can still receive the editor/viewers with getEditors() or getViewers(). If you manually share a file you can see all email addresses as well.
So if you ask me, the privacy issue is a valuable argument, but it does simply not apply here.
Jan
Since this question was posted, Drive API has been updated to allow permissionId to be sent on permissions.insert() (the id attribute). This allows for migration of ACLs without ever needing to know the email addresses (just straight copy the permissionIds over to the new file).
Additionally:
the permissions.getIdForEmail() API call provides a quick way to get the ID for a given email address
when returning permissions for a file with permissions.get() or permissions.insert(), the domain attribute is included which should help determine if the ACL raises security concerns.
I believe these features cover most use cases where the actual ACL email address retrieval was needed.
You are absolutely correct, the email address is hidden for privacy. It is not right that a user should see the email addresses of all other users that have access to the file. But I'm not sure I quite get the problem. Are you migrating using service accounts, or are users individually authorizing the migration?
The value in the permissions feed is consistent for each user, and that value is available in the about feed for a user. I assume you know the email address of the users, so you can authorize for each of them With a service account, and you can migrate the data.
You should not need the Drive API scope and the Docs v3 API scope, they are pretty much the same scope.
Also resurrecting this old thread, I had the same issue while migrating documents.
A workaround:
- Create a temporary folder
- Insert a permission for the user
- retrieve the id from the permission
Not nice, but works for me.