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!
Related
I want users to my website to use Google Accounts to authenticate / sign in to my website. The primary use case being users will edit and generate content and we want to log ownership in a secure way. We are not interested in obtaining users Google data, we just want a means to authenticate users.
After googling, I came across some documentation, which seems to explain how to do this OpenID Connect (OAuth 2.0 for Login). But the documentation immediately says "Note: If you want to provide a “sign-in with Google” button for your website or app, we recommend using Google+ Sign-In, ...", which if you follow the link ultimately takes you to Google+ Sign-In.
What's the difference between these two pages of documentation? Why does the first tell you to go to the second while not saying the first is deprecated? Are both/either suitable for my use case? All it says is "we recommend" I want to know WHY, WHY do they recommend it?
UPDATE: I also found yet another link which seems to be documenting another approach https://developers.google.com/accounts/docs/OAuth2WebServer I think this is just for "Authorization" i.e. authorizing your app to make google api calls to get user data, so cannot be used for authenticating/sign-in.
BTW I'm building my website with a Scala Spray BE REST API & NG JS FE.
A comparison of the two is available here.
Google+ Sign-In with profile scope
Has Google client libraries for authenticating with OAuth 2.0, which includes support for Google+ and other Google services (like getting social information on a user). Also this can make implementing easier and requires less boiler plate code
Has the Google+ Sign-In button to simplify sign-in Has no pre-built widgets
Supports over-the-air Android installs
OAuth login is primarily just for authentication at a lower level, that is by making raw HTTP requests, no API.
OpenID Connect protocols (OAuth 2.0 login)
Google+ Sign-In supports OIDC interoperability if you configure with the openid scope and get the user profile using getOpenIdConnect.
OAuth 2.0 login supports OIDC directly. Use it for signing in users to apps that do not need social features and run on platforms not supported by Google+ Sign-In.
I'm trying to figure out what I need to do in order to achieve seamless SSO sign up.
When an administrator of a domain installs my google app, all of the users on his/her domain, should be able to sign-in through SSO without seeing any confirmation prompts. I'm looking into documentation on how to set this up:
Instead of displaying a confirmation page, your application should
match the value of the openid.realm parameter in the OpenID request
against the value declared in the application's manifest.
Is there an example of this? Also, I think Google stopped using XML manifest files once they switched from OpendID to OAuth 2.0. If so, how does this whitelist process work with OAuth 2.0?
Should I be utilizing Google Admin SDK?
Since google is moving away from OpenId, white listing instructions are obsolete. Found a blog post about Domain-wide delegation with Oauth 2.0. Google recommends the following:
the recommended authorization mechanism is now to use OAuth 2.0 and
service accounts. Google Apps domain administrators can delegate domain-wide authority to the service account’s credentials for a set of APIs. This results in allowing the application, by using the service account’s credentials, to act on behalf of the Google Apps domain’s users.
instructions on how to set up domain wide delegation - https://developers.google.com/drive/web/delegation
you can find detailed step to achieve seamless SSO sign up at the following url
http://david-codes.blogspot.com/2014/07/how-to-provide-seamless-single-sign-on.html
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
The OAuth2 PHP client code is awesome. It gives great examples on how to use OAuth 2 with Google APIs. The problem is that I only want to use OAuth 2 for authentication NOT for authorization. I've looked around in the API for something that just authenticates but I can't find the right class.
How do I configure the Google PHP client to only authenticate via OAuth?
I considered just authenticating the client (i.e. `$client->authenticate($_GET['token'])) but that's not ideal because the user is still asked to authorize access to different resources. I don't want to see their email, picture, etc. I just want Google to verify that they are who they say they are.
Well, OAuth is an open standard for authorization and not for authentication!
Most providers however give you the chance to query a users profile, so you can authenticate the user. Without the access to his profile data, especially his user id, you can not achieve this.
See Google's documentation for obtaining the user's profile information for login.
If you only want to use authetication you have to use: OpenID / Federated Login.
See: https://developers.google.com/accounts/docs/OpenID
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.