Currently using the OAuth server side one-time-code flow, discussed here:
https://developers.google.com/+/web/signin/server-side-flow
Works perfectly for google login.
I want the ability, though, to limit this login to only work for users that belong to a specific apps domain.
Is there any way to enforce this through the api?
OR am I limited to only doing this on my end after google authentication by regexing the email domain? (I would like to avoid this).
Thanks!
There is no support for doing this through Google login. We could allow a developer to set some restrictions on the client id if there are good use cases and a lot of developers would benefit with it. The primary issue I see with is the error message that we have to display to the user. It is better to display that error (and explain) on your site.
In general, as a good practice, you would always want to do the checks on your system/services regarding the authorized user (e.g. check domain)
The only way I can see to do this on the API is to use the fully server side flow (OpenID Connect).
The docs are here:
https://developers.google.com/accounts/docs/OpenIDConnect
With the parameter of interest here:
https://developers.google.com/accounts/docs/OpenIDConnect#hd-param
It doesn't appear to be possible with the server side one time code flow
Related
We have a page on our site that uses Google's reCAPTCHA before allowing the user to download a file.
It works great and we totally stopped all the evil bots from spamming our servers.
Now we want to allow a specific entity (user, domain, whatever) to be able to automatically download files without solving the challenge. Or maybe solving it once per session (which will be longer than 2 minutes) and not once per file.
Is there some way we can issue them a multi-use token or have them get a token from Google that will allow them (temporary?) unfettered access to our file downloads? Can we whitelist their domain in the Google admin settings?
Or is this something I need to build myself?
EDIT: It turns I didn't get all the requirements for this assignment. Whitelisting will not satisfy the requirements since it is apparently multiple entities, and that will indubitably change in the future.
reCAPTCHA does not provide specific whitelisting for users or domains.
Instead, you should be looking at making this dynamic on your side. For example, disable reCAPTCHA for signed-in users or generate a token on your server with an expiry time, set that as a cookie on the client, and disable reCAPTCHA for valid tokens.
I have this example - Embed API Third Party Visualizations - working locally and on a test server, but I'm unsure of what I need to do to ONLY display our organization's Google Analytics data instead of the user's personal GA account.
I created the project and clientID within our org's Google Account, but I'm obviously not understanding something big here.
I'm completely new to both GA's API and oAuth in general, so while I'm sure this has been answered multiple times, I wasn't completely sure which direction to look in. If someone can give a helpful nudge in the right direction I'll happily be on my way.
Thanks everyone!
Embeded API uses Oauth2 to authenticate. Oauth2 requires that a user give you access to their Google Analytics data.
You want to show your person Google Analytics data to other users. Normally I would say you should use a Service account, a service account gives the application direct access to a specific account it has to be set up like you would add a user to Google Analyitcs. The problem is the Embeded API uses JavaScript, for security reasons its probably not a good idea to use a service account with JavaScript. I also think it may be against Googles terms of service to use a service account with JavaScript. That being said I have never found anyone who has gotten a service account to work with JavaScript probably for the reasons I just stated.
Drop the embedded API and switch to a server sided language of some kind and code it yourself. What you want to do cant be done with the embedded API.
I am trying to build a small toolbox of scripts such that I can automate some tasks involving Google contacts, calendar and so on. Most of the work is already done by means of the googlecl project, which looks very promising.
As far as I understand the process, googlecl needs to request an authentication ticket from Google by means of OAuth. Admittedly, I have only a sketchy notion of what is going on there, but that’s something that Wikipedia will help me solve.
Here’s the catch: My Google account uses a non-Gmail address (let it be vucar#example.invalid for the sake of this discussion). The account was created back in the old days when Google didn’t force GMail down people’s throats who have no use for it. googlecl will direct me to https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=…&hd=example.invalid to complete the OAuth handshake. Google will then tell me that ‘the domain name has not been signed up for Google Apps’. Which is correct.
If I don’t supply my user ID to googlecl, then the URL reads …&hd=default. Google will accept the OAuth request, granting whichever permissions needed to my locally running googlecl, but then googlecl will complain that the token was issued to a different user ID than for the user ID that was requested. Which of course is also correct.
I’ve read through https://support.google.com/a/answer/33419, which in turn redirects me to http://www.google.com/a in order to ‘to sign up your domain for Google Apps’. Apparently, if my Google account uses a domain different from #gmail.com, then I am a business user and need to purchase Google Apps for my domain—to get, amonst a truckload of other stuff, my domain connected to GMail, the polar opposite of what I wanted to have by having that ‘foreign’ domain in the first place.
I have to admit that I am stymied. I understand what OAuth in this case is used for, but I fail to grasp the byzantine reasoning at Google’s. I do not believe that I want Google Apps for my domain, and I especially do not want to hand over my emails or anything else to Google. I merely want to access and modify my data at Google’s, with my user ID happening not to end in #gmail.com.
Is it strictly required that I purchase Google Apps for Work for such a configuration? The contacts, calendars and so forth is already at Google’s, and used from both Google’s web site and Android clients. The only thing new to the mix is API access.
I have a google calendar that I have marked as shared. it stores all appointments for the day.
I have a webpage. from the webpage, the user enters a date and I use the google api (javascript) to pull back all info from my shared calendar for that date and present it to the user.
I also want the user to be able to make appointments during free times on any given day.
problem is, I must be signed in to my google account. if I am NOT signed in, I get a little popup asking for my userid/password.
how do I get rid of that? I had hoped that making the calendar shared and specifying the client ID and api key (assigned via Google's API Console) would have been enough.
I've run across this: http://cornempire.net/2012/01/08/part-2-oauth2-and-configuring-your-application-with-google/ which explains doing this via Oath and refresh tokens in PHP.
unfortunately, I'm doing this in javascript and MUST do it from the client side. is that possible?
I think you should look into using a service acccount for this.
http://code.google.com/p/google-api-php-client/wiki/OAuth2#Service_Accounts
By using a service account you wont have to worry about people loging in. They will have access to the calender for the service account.
Update: I have searched for examples of how to do this in Javascript and have been unable to find any. After considering this issue for a while now i have come to the conculsiton that even if you could use a service account via javascript for security reasons its probably not a good idea.
Unfortuantly this leaves me to beleave that the anwser to your question is No. You cant do this client sided. If you use normal OAuth2 its still going to prompt you for the autentication. You need to try and reconsider a server sidded option. PHP for example
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.