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.
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.
It seems like chrome.identity.launchWebAuthFlow is the way to go. I found resources that explain how to implement it client-side but they all say nothing about how to authenticate server-side for non-Google accounts:
"The provider will perform authentication" - how?
"Validation of the returned access token isn't shown here"
It seems that the last missing ingredient is to write server-side (ideally Python) code that listens on my app's server and validates URLs such as:
https://www.my-app.com/dialog/oauth?client_id=123456789012345&redirect_uri=https://abcdefghijklmnopqrstuvwxyzabcdef.chromiumapp.org/provider_cb&response_type=token&scope=user_photos
I'm guessing that would be done by another Chrome Identity API call from my application's server. I looked through a large number of resources (and related stack overflow questions) and they provide no clear answer. Thanks!
[migrated discussion here from this question]
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.
When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.
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.