Migrating OpenID2 to OpenID Connect or Google+ Sign-in - asp.net-mvc-4

My ASP.NET MVC 4 application uses OpenID2 authentication that went with MVC templates (out of the box) and only uses Google accounts for authentication, no other social features are integrated.
Now I need to migrate OpenID2 because it will be shutdown in April:
Migration OpenID2
It seems that I could use one of two options to do this migration:
OpenID Connect
Google+ Sign-in
I would like to understand better which differences between the two methods and the advantages/disadvantages of one related to the other.
Until now, I think that the biggest difference is that OpenID Connect is used essencially to authentication and Google+ Sign-in has authentication and social features. Am I right?

Google+ Sign-In provides OAuth 2.0 (OpenID Connect) authentication with rich social features and access to additional Google desktop and mobile features.
Right from the link you have you can see that Google+ Sign-In is OpenID connect. Using Google+ Sign-In however adds some social features and some usability improvements for getting integrated into your site.

Related

How does Google's Sign On Work? OAuth2.0? SAML?

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)

What's the purpose of Auth0 SSO Integrations?

Under the Auth0 dashboard, there is an option SSO Integrations with a number of listed applications such as Active Directory RMS, SharePoint and so on.
What does this exactly do? I'm trying to find some documentation around this.
The SSO Integrations provides you a packaged experience so that you can quickly configure any of the listed applications to use Auth0 for authentication.
This does not mean that you cannot integrate applications not mentioned in the list; it just means that those, possibly due to popularity, got special treatment.
For an example on integrating with Slack, check this tutorial (Integrate Auth0 with Slack).
You can configure Slack to login with Auth0. That way, users would be able to login with any of the identity providers supported by Auth0, such as Active Directory, LDAP, Google Apps, Facebook, Google, Twitter, and so on.

Difference between Google "OpenID Connect" and "sign-in with Google"?

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.

OpenID in backend REST API

We are designing a web service for an application that takes OpenID as an authentication option. The question came up how do we enable API access for this user at a later time?
For clarity here is an example:
1) user A visits the site and registers using Yahoo (or other) OpenID
2) at a later time we'd like to enable API access to backend synchronization apps that act on behalf of this user.
3) giving an app a key that can access all accounts everywhere is not an option for security reasons
What are examples of using patterns like that?
Standard OpenID requires a browser because it depends on being able to load a page from a foreign site to complete the signin process. Therefore it's not appropriate for server-to-server API use.
It is more common to use OAuth as an authentication mechanism for server-to-server APIs. While standard OAuth also requires a browser and a user-interactive flow to grant access to a new application, it results in a token that can then be used by the application to act on behalf of the user for user-unattended requests.
Facebook is possibly the most high-profile user of OAuth 2 for APIs, and its Login Architecture document describes the various login flows they support at a high level. The one titled "Server-side Login" is the conventional OAuth flow, while others are different approaches that support different use-cases like mobile app sign-in and access from client-side JavaScript embedded on other sites.

The difference between using Janrain and OAuth?

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.