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.
Related
Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.
According to the Google Drive documentation, an application needs a so-called "client secret" in order to interact with the Google Drive SDK -- even if, as in the case of a client-side JavaScript app, the code is plain for all to see. (Of course, it's not really that much safer in any other client-side code, it just makes for a bit more work to find the "secret"...)
So, um:
How is it okay to distribute these "secrets" inside applications?
Is there any reason why that logic wouldn't apply to open source computer programs?
BONUS: Wouldn't it make more sense to just use user-based authentication for such apps, without pretending to authenticate the app as being a specific app?
Whilst it's true that a Client Secret is generated for all apps that consume Google services, the Client Secret is never used by a browser/javascript app. Typically a browser-app (I use the phrase "browser-app" instead of "Javascript app" because a server node.js app is also using Javascript) would authenticate and authorize using the gapi library described here https://developers.google.com/api-client-library/javascript/reference/referencedocs#gapiauthauthorize. As you can see, Client Secret is never used.
So, picking out your questions ...
It isn't OK, don't do it, no need, see above.
See 1
You're conflating authenticating the user with authenticating the app. Both are needed, each for different purposes. In the case of a browser app, the authentication is done using a combination of the client ID, verified against the http origin (which the developer has previously declared to Google). Once the app is authenticated, we can then move on to authenticate the user by leveraging the OAuth authorization mechanism in conjunction with an extant Google session.
I have a general comprehension question about OAuth access token retrieval for a Google Chrome Extension.
I have a popup HTML window in the browser that uses Jquery to request data from the server (a LAMP stack on AWS). The data is presented by PHP scripts which access a MySQL database. All very basic stuff.
I now want to implement a push messaging system using Google Cloud Messaging to alert users of new content that they can check. However I don't really understand where I should request the access token and how to listen for the response. I figure it should be in the PHP scripts but all the Google documentation that I've read states the user has to be present in order to allow access to push messaging. That tells me I should put it in the JavaScript but I feel this is a bad idea because every user could potentially request an access token when I think I only need one every 3000 seconds or so. If my app was completely implemented in PHP I'm sure this would be possible and now I'm worried that splitting it up like this leaves push messaging out of the question. Am I missing a crucial detail or just out of luck?
If the data access you need isn't user-specific, then you're right, there's no good reason to get a separate token for each user. Check out https://developers.google.com/accounts/cookbook/roles/Apps which discusses some options.
In the scenario of scripts that need authentication to run (run as service account, locked down sharing settings, etc) is there a way to authenticate as a Google user via an HTTP tool like cURL, UrlFetchApp, or even PowerShell scripts from Windows Server environments?
You are going to have to do a little leg work on this one.
Firstly, when you publish your apps script, make sure to change the "who has access to the app" to something like "only myself".
Then you need to see what happens when you try to hit that URL from an external service without authenticating. There may be some help from the error codes you are likely to receive.
I imagine you can then use the following documents to Authenticate for Google Services IN GENERAL. Then you will most likely have to pass a sessionID or Accesskey of some sort. I only have a brief understanding of OAuth, but I do imagine that you may be able to set up a more permanent connection between your other server and your particular Google Apps Script.
I hope this helps.
Jacob
I am looking at creating a good google chrome extension for tumblr.
Now tumblr uses Oauth as it's authentication method.
So my question becomes.
Do I:
Distribute a single key with the application and hope people are nice enough to not use it for illegitimate purposes.
Put in the options the ability for a user to enter their own key, hence asking each user to register an application.
Create an intermediary on my server that makes the actual request.
Something else?
I also had to consider this for my Template extension when using OAuth to communicate with the goo.gl URL shortener service on the user's behalf.
After reading Chrome's OAuth tutorial I managed to implement this simply using the following;
ChromeExOAuth.initBackgroundPage({
access_url: 'https://www.google.com/accounts/OAuthGetAccessToken',
app_name: chrome.i18n.getMessage('app_name'),
authorize_url: 'https://www.google.com/accounts/OAuthAuthorizeToken',
consumer_key: 'anonymous',
consumer_secret: 'anonymous',
request_url: 'https://www.google.com/accounts/OAuthGetRequestToken',
scope: 'https://www.googleapis.com/auth/urlshortener'
});
This is surrounded by quite a bit of logic due to the complexity of the extension but this results in the user simply being shown a page (on a new tab) the first time they attempt to shorten a URL using my goo.gl implementation. Here the user can decide to allow/deny the authentication. Since this is only done once (unless the user later removes it from their list of authorized applications) I thought this was fine and my users seem to agree.
I did also provide an option to toggle OAuth on/off but I'm guessing this will always be required for the tumblr API. On that note I must admit I'm not familiar with that particular API so I'm afraid I can't help you further.