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.
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'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
I am building a basic app using node.js and mysql and just getting a hang of it, I would like to secure the api,like only allow certain people to access the data, maybe by passing a certain token each time a user requests for some information, I tried searching for certain tutorials which used node.js and mysql database and security, I am confused as to which security measure to use, I even read about Json Web Tokens but din't find a proper tutorial for that.Please point me in the right direction.
EDIT
What I meant to say was, only authenticated users are allowed to get access to data in the api, when a random visitor tries to access a URL he shouldnt be alowed to without proper authentication,what I am mostly looking for now is when a user is authenticated the user should be a sent a token of some sort so then gets access to private data,I don't exactly know how to go about this whole thing.Would be glad if you could clear it up for me.
I would look at implementing Oauth2 server in your app. I found this article useful:
http://blog.papersapp.com/oauth-server-in-node-js/
No sure what your exact question is about, but I think the below will help:
Node.js security tips: http://blog.risingstack.com/node-js-security-tips/
Secure Express apps with various HTTP headers: https://github.com/helmetjs/helmet
Go on an educational Web security adventure: https://github.com/toolness/security-adventure
Node.js Security presentation: http://www.slideshare.net/d0cent/nodejs-security?qid=c450507b-e491-4e9a-9b05-89d0c82ea10b&v=default&b=&from_search=6
Take a look at http://passportjs.org/ . Passport has support for alot of authentication methods, however, for your API, you will probably want to use OAuth (http://passportjs.org/docs/oauth2-api). OAuth is what most popular APIs use to authenticate consumers.
For simple projects, You can also use basic authentication, which is what you see when you see the browser prompt asking for username and password. This authentication information can be sent in the header when API consumers makes requests.
I'm working on a an application where my back-end server will push and pull data over the google drive sdk. So, the back-end will only ever need a authorization via a single admin user's set of credentials.
Is the best way to do the authorization for this use-case to do what's described here?
https://developers.google.com/drive/web/auth/web-server
It looks like I would manually authorize my back-end's user once and store the refresh token for later offline access, thereby not needing manual/human interaction ever again.
But is that actually the best way for this use case? Is there another authorization workflow that I've overlooked?
The method described at the link you sent is appropriate when you are authing several end users. I find it's overkill if you only ever need to auth a single user. Too much code and faffing around for something that will only be used once.
Check out How do I authorise an app (web or installed) without user intervention? (canonical ?) which is a one-time procedure which gets you the same result, without writing any code.
Having worked on it some, I think the best way for my application is this:
https://developers.google.com/api-client-library/python/auth/service-accounts
You create a Service Account through the admin console. There's no messing around with a manual authorization step that could later break the app.
I am trying to make a simple integration to BOX where I only access my own account. Since this is a server-side access, (the server-process calls the Box-api), having the Oauth 2.0 redirecting is a problem.
Is there a way I could acquire a token (even manually) and use it in my code, by-passing the hassle of Oauth 2.0 and the redirection ? Or may be some other way for this kind of scenario ?
Right now you can do this with a Developer Token, but that only lasts for 1 hour.
You can also do the auth on your laptop, then put the Refresh tokens into your server in a config file, much like you might do for a database-password file (hopefully only readable by the service-account on the machine that has access to run your script).
Then build your script to take the refresh-token, go get a token pair with it, and write the new refresh token into the config file.