Our clients use Google Apps for Education. We are implementing single sign on from Google Apps to our web application, using Google Apps as the identity provider. Due to the security issues related to working with students, it is not possible to allow students to create accounts in our web application using their Google Apps account. Instead, the user accounts in our application store the Google Apps account name.
So far, we have set up OpenID in Google Apps and it is working. The student enters their Google Apps username and password at the Google prompt, then approves the sharing of their username. The application uses the username to match the existing account so the student is logged into the correct account in our application.
Since our web application is trusted by the school district, we would like to eliminate the step where the student approves the sharing of their username. However, we haven't figured out how to do this. Is there a way to configure Google Apps to trust our web application using OAuth 2.0?
We are thinking that 2-legged OAuth may be the way to go. It is described in this article. Is this the correct approach for what we want to do?
Using 2-legged OAuth with Google Tasks API for Google Apps domain administrators
From what i Read about 2-legged OAuth allowed to access to the user's resources without asking for their permission to do so .
if you want to display for example all events from Google calendar of students if you do it by an ordinary way u will need to ask permission from each student to access to their calendar but by using 2-legged OAuth with Google Apps for Education you don't have to .
you find here link more infos about 2-legged OAuth and comparing it with 3 legged Oauth with an example
Related
Google Drive API question,
I am writing an application that can view a users' Google Drive files and folders from their google account (can be individual or part of an enterprise).
So on my Google Drive enterprise, I have created an API application. So I have an API key and Secret key stored in my application.
Now I want to use OAuth to authenticate the user so that they can approve my application to read their files. The users will not be part of my enterprise. They can be individual Google accounts, or they can be a single user from an some other enterprise account.
Is this possible? Or are there technical/security reasons this is not allowed?
I just got off the phone with wonderful Google api support agent, and I have my answer:
Yes this is possible to do. however due to the recent phishing attack, Google has put in place new security features that affect the following APIs:
Google drive
Gmail
Contacts
Directory Admin SDK
Here are the new rules:
There is a new security form we will need to fill out and be approved before we will be able to be approved as a trusted app that is able to access these api's using OAuth2 authentication.
Google has provided a feature that many enterprises use that allows an enterprise to completely disable the ability to access these api's using oauth2. So even though we have been approved from step1, we may still get an error for some enterprises who have directly blocked this; however, they can white list us in order to allow it from our enterprise if admin's prefer, while still blocking general use for others.
See links:
https://support.google.com/a/answer/7281227
https://developers.google.com/drive/v3/web/about-auth
https://developers.google.com/identity/protocols/OAuth2
https://www.reddit.com/r/google/comments/692cr4/new_google_docs_phishing_scam_almost_undetectable/
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
We currently have a corporate portal in which users authenticate and get different page views based on their access level. We have been tasked with allowing them to click a Google Mail icon to sign them into their domain Google Mail Account. To do something like this, should we be looking in to oAuth or Open ID? Presently, they're already using their email and password to sign in.
From what we understand, Open ID requires their email and password to go to us, which we have; but will Open ID do what we're looking for?
Thank you.
Since your users have a Google Apps for Business email address already, I would suggest using the Google+ Federated Login feature-set. (You can learn more here: https://developers.google.com/accounts/docs/OpenID)
A quick snippet from the aforementioned link:
If you are planning to provide a “sign-in with Google” feature, we recommend using Google+ Sign-in, which provides the OAuth 2.0 authentication mechanism along with additional access to Google desktop and mobile features...[the] OpenID+OAuth Hybrid protocol lets web developers combine an OpenID request with an OAuth authentication request. This extension is useful for web developers who use both OpenID and OAuth, particularly in that it simplifies the process for users by requesting their approval once instead of twice.
You can find more on the Google+ Federated Login toolset and explore a sample application here: https://developers.google.com/+/
Hope this helps!
So I am creating an application for my google apps domain. It will have its very own google apps account associated with it, from which it can store/retrieve/manipulate data.
The application should use this google account alone and the user should have no indication that it is using a google account. Is there a way to programmatically authenticate my entire application and not prompt the user authenticate/authorize?
I think you are looking for two legged OAUTH.
You can generate a OAUTH token and secret in the control panel of Google Apps and assign the authorized scopes to this token/secret pair. For instance, you can authorize access to the calendar of all users in your Google Apps domain using the token/secret.
You can then programmatically access the calendars of all users.
Because this token/secret is authorized by the Google Apps domain administrator, individual users do not need to grant access anymore. That is why this is called two legged Oauth, whereas three legged Oauth requires user interaction to obtain a token/secret for an individual user.
This question on SO might interest you too.
I was just wondering, I want to associate a Twitter and LinkedIn account with my systems accounts. Which would allow them to post to interact with them without needing to log in to the other systems.
Is there a way to store the social (twitter / LI) usernames and passwords and associate them with my system and vis versa.
E.g. If I login using my native details (email / password) I can access the API features of my social network accounts?
Thanks in advance,
Chris
I can't speak for Twitter, but with LinkedIn you could follow this basic workflow:
Register an 'application' with LinkedIn. Your site will use this application for all communication with the LinkedIn API.
Have the user authorize your site (your application really), to access their account via the LinkedIn API.
Retrieve the user's unique LinkedIn ID, as well as their access tokens, and store those in your user account database, associated with their existing account.
Then, when they return and log in to your site, any calls you need to make to LinkedIn can be done via the stored access token, rather than having to have them manually allow you to have access again.