I am curious about how Google's Authentication works. Does it use OAuth2.0 for Authorization? Or SAML for authentication? I tried intercepting the requests and responses, but I cannot determine how their authentication/authorization flow works.
Thanks in advance!
Signing in with a Google Account is based on OpenID Connect (OIDC). Google produces wrappers (libraries..) that do a lot of useful things on top of plain protocol. From Google's OIDC page:
If you want to provide a "Sign-in with Google" button for your website or app, we recommend using Google Sign-In, our sign-in client library that is built on the OpenID Connect protocol and provides OpenID Connect formatted ID Tokens.
G Suite also supports SAML for SSO to 3rd party apps. (You still authenticate with your Google Account)
Related
I see that Bluemix Mobile client access service lets me use Google, Facebook and Custom IDs to login to the mobile app.
Is the custom IDs login option similar to OAuth? The documentation refers to this lightly, but I'm not clear here.
Thanks,
Chaitanya
MCA uses the OAuth2 protocol.
From the docs:
The Mobile Client Access integration enables any web application, regardless of the technology it implements, to take advantage of the OAuth2 protocol.
Here's the Node.js OAuth SDK and two custom identity provider samples that might help clear things up:
https://github.com/ibm-bluemix-mobile-services/bms-mca-custom-identity-provider-sample
https://github.com/ibm-bluemix-mobile-services/bms-mca-custom-identity-provider-with-user-management
When you write your own custom auth, MCA uses the OAuth2 protocol with your custom auth code as the token endpoint. After you authenticate/sign in against your custom implementation, MCA provides a token that you can use to access MCA's authorization endpoints.
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
We're building a public API and clients using this API will need to authenticate, and we proposed to expose an OAuth2 API for this purpose.
However, we also have a need for authentication to be federated, so we see clients talking OAuth 2 with our API, and our API talking OAuth1/2 or SAML2 to the identity provider in the background.
The full flow being:
Client talks OAuth2 to our API.
At the start of this flow, our API redirects the client to a "Choose Your Federated Provider" HTML page.
On choosing a provider, our API talks OAauth1/2 with the provider, passing any redirects back to the client, so the user can provide login details.
Our API exchanges the access code for a access token and refresh token (API keeps these private, and uses them even if the client is off-line).
Our API generates an access code and passes this to the client.
Client exchanges the access code for access token.
The provider supplied access token/refresh token is use by the API in the background, for example to keep a Google calendar up to date, and not passed to the client.
I've not found any examples of this being done with an API. So, what is the established model for providing federated authentication for an API service?
Check out some of the info that Ping Identity provides on their OAuth Essentials page. Specifically, there is a White Paper entitled, "A Standards-based Mobile App IdM Architecture White Paper" (free w/Registration) that you should look at that talks about how you would use SAML + OAuth to secure Native Mobile Apps that require Federation. [Note: I do work for Ping]. It lays out the info flows and token exchanges that need to happen to solve this use case as well as other OAuth related cases.
HTH - Ian
Im using Janrain at the moment and dont know much about OAuth.
Could someone explain the differences between these two?
Janrain is using OpenID, so the user must get an identity with an OpenID provider. You already know how it work: User interacts with a provider that prompt for credentials. OpenID is a good solution if you want a Sign-In system that accept existing accounts from OpenID providers.
In the case of OAuth, it can be completely transparent to the end-user. OAuth works with Tokens and each token grants access to a specific site or resources, it's all about "authorization". You can also configure a token to expire after a defined duration. OAuth can also be used for Login, that's how Facebook works.
Example with OAuth:
Your website use Janrain for authentication, and now, you want to allow users to import photos from Facebook, but the user provider is Google (for example). You will redirect the user to Facebook for authentication and the user will be asked if he want to grant access to your website. If the user agree, he will be sent back to your website and in background, you'll get a Token from Facebook which must be used in future communication to validate actions. At no point the user shared username and password with your site.
I recommend you to read on OAuth. You can see a really good guide here, for both OAuth 1.0 and 2.0.
Janrain Engage is a set of widgets and backend technology to support a variety of identity providers who may be authenticating through various flavors of openid and oauth. Shielding you from implementing the protocols required to support the over 20 identity providers that Janrain supports.
There is no difference between Janrain and OAuth. Janrain is not a particular protocol for social sign in. Janrain creates a set of API's that work with both OpenID and OAuth - so you don't have to know the difference.
like Kevin said, Janrain's Social Login is back-end technology that supports a variety of identity providers who may be authenticating through various flavors of openid and oauth.
So there really is no difference between Janrain and OAuth, it's just that Janrain uses whichever technology the provider is using in their social API - OpenID and/or OAuth.