Stateless RESTful API and 3rd party authentication - authentication

I want to use 3rd party authentication (OpenID, maybe OAuth but I guess OAuth is meant for authorization) so that user can login easily.
But does authenticating on every request means I call the 3rd party (eg. Google) many times even if I don't need any thing from it? For example, I use OpenID authentication but the API I use is something internal (eg. /api/tasks/add).


Let's fix understanding issues first. OpenID and OAuth are a bit different. There is a simple way to memorize that different:
OpenID is for humans. Simple example: you want to skip boring registration step and let user reuse existing account.
OAuth is for services/robots. Simple example: you want your script to access external API with some user's data.
There is a simple explanation provided by wikipedia:
Note that with OpenID, the process starts with the application asking
the user for their identity (typically an openid URI), whereas in the
case of OAuth, the application directly requests a limited access
OAuth Token (valet key) to access the APIs (enter the house) on user's
behalf. If the user can grant that access, the application can
retrieve the unique identifier for establishing the profile (identity)
using the APIs.
So I want to use 3rd party authentication ... that user can login easily. would probably mean you are going to use OpenID.
Answering your question: you do not need to call any third-party services on any request. It will be very inefficient and slow. OpenID provider will return user's credentials and you are good to go.
Please make sure you have identified requirements correctly.


OpenID Connect is an authentication mechanism written on top of OAuth2. The client obtains a bearer token that it can send in an Authorization header with each request to the resource server.
This ID Token is a JWT, signed by the OpenID provider. A decoded token looks something like this:
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"exp": 1311281970,
"iat": 1311280970
}
So it can be verified by the resource server without needing to contact the OpenID provider. The OpenID provider has a User endpoint where the relying party can fetch more detailed user info that is not included in the token, such as name and email address.


I believe both the answers by Renat Gilmanov and flup should be useful to you, but I will try to just answer the question that was asked, here.
No, it does not mean you contact the 3rd party site on every request. In fact, you can't, since the whole OpenID process should just happen once for a given session (it's a somewhat annoying manual step for the user)
I'll refer to the OpenID provider (3rd party) as Google, since that's the example you gave in the question.
The only thing that Authentication will do for you is give you Google's assurance that the person making that particular request also knows the password to the Google account name they gave you.
After that, it's up to you to keep track of requests coming from the same "person" and treating them as the same account. Basically, however you're handling the rest of the user's "session" information, you can now assume that all requests in this session are from that user.
The most common way would be through passing a cookie to the browser immediately, which contains some identifier that you keep track of on the server, and that confirms for you that whoever passes you that cookie is also the person who knew the password for that Google account. Another option would be sending custom HTTP headers, which is preferable in certain ways, but trickier to do by hand.
You could build all of this manually, but I would very strongly recommend finding some library code to take care of as much of this for you as possible. You don't mention what you're using to build this Web Application (in fact, you don't explicitly say it's a web application, I just gleaned that from the way the question is tagged), but there are plenty of choices for pretty much every framework or system you're likely to be using.
On some level, everything I wrote applies if you're writing an API for a native mobile app to connect to, as well. But you may have to jump through some slightly more complicated hoops in order to have the user authenticate, since some OpenID providers assume you're coming through a web browser.

Related

Securely using JSON web tokens to programmatically authenticate a user from one system into another

My team and I have been working on a web application for our clients that uses JSON web tokens for authentication and authorization. Using Azure AD as our identity provider, we verify a user's identity and generate a signed JWT with the user's permissions in it. The JWT then gets included in the authorization header of all subsequent requests to the APIs. Pretty standard stuff as far as JWTs go.
We're now being asked to provide the capability to link directly into our system from another third-party web application without forcing the user to reauthenticate. I'm trying to figure out if there's a way to do so without creating a massive security loophole.
The way I picture this working would be to implement an endpoint for programmatic authentication in our system that accepts a cryptographically signed payload with an API key and the user's ID or email address. The third-party system would have a private key with which to sign the payload, and we'd have a public one to verify the signature. If the request is legitimate, we'd issue a token for the specified user, and they could use that to link to whatever they like.
I'm already getting yelled at by at least one person that this is a complete joke from a security standpoint because, among other things, it completely bypasses AAD authentication. I believe the third-party system in question does use AAD for authentication, but that's not really relevant either way because we're trusting them implicitly whether they've authenticated their users or not. Either way I take his point.
I'm not a security expert and I don't claim to know whether there even is a proper way to do this kind of thing, but from my vantage it doesn't really seem all that much less secure than any other mechanism of authentication and authorization using JWTs. Is that true? Are we nuts for even trying? Is there a way to do it that's more secure? What should I know about this that I demonstrably don't already?
Thanks in advance for the help. At the very least I hope this spurs some helpful conversation.

Single Sign-On (SSO) enables users to enter their credentials once to sign in and establish a session which can be reused across multiple applications without requiring to authenticate again. This provides a seamless experience to the user and reduces the repeated prompts for credentials.
Azure AD provides SSO capabilities to applications by setting a session cookie when the user authenticates the first time. The MSAL.js library allows applications to leverage this in a few ways.
MSAL relies on the session cookie to provide SSO for the user between different applications.
Read more in this documentation.

Should HTTP Basic Authentication be used for client or user API authentication?

A typical recommendation for securing a REST API is to use HTTP Basic Authentication over SSL. My question is, should HTTP Basic Authentication only be used to authenticate the client (ie. the app accessing the API), or can it also be used to authenticate the user (the consumer of the app)?
It seems most APIs have to deal with both, as almost all web services employ some sort of user accounts. Just consider Twitter or Vimeo—there are public resources, and there are private (user specific) resources.
It seems logical that a simple REST API could do both client and user authentication at the same time using using HTTP Basic Authentication (over SSL).
Is this a good design?

By authenticate the client you probably mean the usage of API Key, this mechanism is used to track the concrete application/client. The second thing is that it gives you the possibility to disable the application by disabling the key, for example when client's author removes his account from the service. If you want to make your API public then it is a good idea.
But you need to remember that it gives you no real protection, everybody can download the client and extract that key.

I would not recommend to use Basic Authentication for API authentication. When it comes to authentication then you should consider that the application (client) developer has to implement its side of the authentication, too. Part of that is not only authentication itself but also how to get credentials and even much more than that.
I recommend to make use of an established authentication standard that ships with client libraries for the most popular programming languages. Those libraries make it much more likely that developers are going to adapt your API, because they reduce implementation effort on the client side.
Another important reason for using authentication standards is that they make developers (and others) more confident in the security of your authentication system. Those standards have been audited by experts and their weaknesses and strengths are well known and documented. It is unlikely that you are going to develop a nearly as solid authentication flow unless you are a security expert :-).
The most established standard in this field is OAuth but you can find alternatives by searching for "oauth alternatives".
How does OAuth help you with your problem setting?
In OAuth 2, the application client has to obtain an access token for a user before accessing any protected resource. To get an access token, the application must authenticate itself with its application credentials. Depending on the use-case (e.g. 3rd party, mobile) this is done in different ways that are defined by the OAuth standard.
An access token should not only represent a user but also which operations may be used on what resources (permissions). A user may grant different permissions to different applications so this information must somehow be linked to the token.
How to achieve such a semantic for access tokens however is not part of OAuth - it just defines the flow of how to obtain access tokens. Therefor, the implementation of the access token semantic is usually application specific.
You can implement such token semantic by storing a link between an access tokens and its permissions in your backend when you create the access token. The permissions may either be stored for every user-application combination or just for every application, depending on how fine-granular you want things to be.
Then, each time that an access token is processed by the API, you fetch this information and check whether the user has sufficient permissions to access the resource and to perform the desired operation.
Another option is to put the permission information into the access token and to sign or encrypt the token. When you receive the access token, you verify or decrypt it and use the permissions that are stored in the access token to make your decision. You may want to have a look on Json Web Tokens (JWT) on how to accomplish that.
The benefit of the later solution is better scalability and less effort during backend implementation. The downside of it are potentially larger requests (especially with RSA encryption) and less control over tokens.

How to use OpenID or OAuth for internal first-party authentication?

I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
Are OpenID/OAuth suitable for authentication among first-party services?
If so, how would one be advised to set up authentication for this use case?
Wouldn't a user have to grant individual permission to each first-party server that they wanted to use, just as they would need to grant individual permission to any third-party server? I think this would violate the requirement of having a single sign-on for accessing all the first-party services.
Are there good examples of sites supporting this first-party use case?
What would be a good alternative framework for this first-party use case?

You do not need OAuth for SSO services.
The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.
Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.
As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).
So basically what I'm proposing is:
When an app tries to access the first API it's redirected to a web-form.
The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
Next API access request would be made with that token - the token uniquely identifies the app
Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.
In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.
What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.

Oauth supports multiple different kinds of flows. You can use the client crendentials flow from Oauth 2.0 to avoid asking the user to grant permission for every app (this is intended for the cases where you control both the server and the app or where you want to preauthorize certain apps). This post does a good job explaining everything: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/

Can I use extension to pass login and password to OpenID provider?

There will be login page via OpenID controlled by an extension. Can I ask for URL and pass in the extension and then pass it OP by use of extension? If no what kind of data can be transferred to OP from RP by an extension? If yes, how scalable it is, do I have to write separate code of each OP, or will the standard help me?
Also in unlikely case of XY problem - I need some sort of data that will allow me to authenticate OpenID user offline (after at least one successful online login). So if I was the one to provide login and password text fields I would be able to use user's password hash it and use for offline auth. And yes I need to use OpenID rather that other system, because this is the requirement. Sorry, It's kind of ugly problem.

I don't think you're supposed to pass a user id/password to the OpenID provider (or at least not password). The idea behind OpenID is that the provider takes care of the login, thus the web application utilizing OpenID will have no knowledge of the login credentials. OpenID provides you with some authorization information, such as the nickname, fullname, email, etc. This information, coupled with the OpenID of the user itself, should be enough provide you with unique authentication for that user without the need to have a password.
Your application needs to allow the user to go to the OpenID provider's page, enter their credentials there, and once authenticated you will get a response from OpenID indicating whether the authentication is successful and subsequently providing you with the user's information.
Update
Like I mentioned in my comments: the OpenID standard does not define a way in which you can send a password to an OpenID provider. So you can't use the OpenID standard in the manner you're envisioning it.
Update 2.0
Let's take myOpenID for example: in order to use myOpenID as an OpenID provider you have to register your domain with OpenID. Alternately, you can enable OpenID for your website by contacting Janrian (the owners of myOpenID), but I'm going to say you're still going to have to register a website with them. In either case, you must have a landing page on your domain, or on your website, which accepts an authentication response from the OpenID provider (in this case myOpenID). So let's look at what's required:
You must spoof a web browser when you're making the web request to the myOpenID provider.
In that web request, you have fill in the form which takes in the client's password (again, you have to spoof the client doing that).
You have to have a service of some sort running on a website registered with an OpenID provider (such as myOpenID).
You will have to send a message (HTTP) to the service that you're expecting an authentication response for a specific user (and provide it with a way to call you back when the user is authenticated).
That service will take any incoming authentication response from the OpenID provider.
The service will match that authentication with the user ID that you told it to expect in step 4.
The service will send your application the authentication response (callback).
You must accept the authentication response from that service.
The hardest part will probably be step 1 and 2, but there should be plenty of tutorials online that can show you how to do this (sorry I didn't have time to look up specific ones).
In any case, that's how I would imagine you may be able to do this, but it's far from trivial and I've never seen it done before.
Part of the reason why OpenID is so popular is exactly because people don't have to share their credentials with the service provider (i.e. your app), they only share it with the OpenID provider. The other thing you should think about is whether or not users will agree to use the OpenID in the manner that you want them to use it. In other words, one of the main reasons why people use OpenID providers is so that they avoid doing exactly what you're asking them to do: give you their password!
Update 3.0
You can register your domain with myOpenID by going to the new domain registration page: https://www.myopenid.com/new_domain

What's the difference between OpenID and OAuth?

I'm really trying to understand the difference between OpenID and OAuth? Maybe they're two totally separate things?

OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
The blog post "OpenID versus OAuth from the user’s perspective" has a simple comparison of the two from the user's perspective and "OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing" has more information about it.

There are three ways to compare OAuth and OpenID:
1. Purposes
OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have. The term federated is critical here because the whole point of OpenID is that any provider can be used (with the exception of white-lists). You don't need to pre-choose or negotiate a deal with the providers to allow users to use any other account they have.
OAuth was created to remove the need for users to share their passwords with third-party applications. It actually started as a way to solve an OpenID problem: if you support OpenID on your site, you can't use HTTP Basic credentials (username and password) to provide an API because the users don't have a password on your site.
The problem is with this separation of OpenID for authentication and OAuth for authorization is that both protocols can accomplish many of the same things. They each provide a different set of features which are desired by different implementations but essentially, they are pretty interchangeable. At their core, both protocols are an assertion verification method (OpenID is limited to the 'this is who I am' assertion, while OAuth provides an 'access token' that can be exchanged for any supported assertion via an API).
2. Features
Both protocols provide a way for a site to redirect a user somewhere else and come back with a verifiable assertion. OpenID provides an identity assertion while OAuth is more generic in the form of an access token which can then be used to "ask the OAuth provider questions". However, they each support different features:
OpenID - the most important feature of OpenID is its discovery process. OpenID does not require hard coding each the providers you want to use ahead of time. Using discovery, the user can choose any third-party provider they want to authenticate. This discovery feature has also caused most of OpenID's problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don't get. Other features OpenID has is its support for ad-hoc client registration using a DH exchange, immediate mode for optimized end-user experience, and a way to verify assertions without making another round-trip to the provider.
OAuth - the most important feature of OAuth is the access token which provides a long lasting method of making additional requests. Unlike OpenID, OAuth does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service. However, since OAuth does not support discovery, it requires pre-selecting and hard-coding the providers you decide to use. A user visiting your site cannot use any identifier, only those pre-selected by you. Also, OAuth does not have a concept of identity so using it for login means either adding a custom parameter (as done by Twitter) or making another API call to get the currently "logged in" user.
3. Technical Implementations
The two protocols share a common architecture in using redirection to obtain user authorization. In OAuth the user authorizes access to their protected resources and in OpenID, to their identity. But that's all they share.
Each protocol has a different way of calculating a signature used to verify the authenticity of the request or response, and each has different registration requirements.

OpenID is (mainly) for identification/authentication, so that stackoverflow.com knows that I own chris.boyle.name (or wherever) and therefore that I am probably the same person who owned chris.boyle.name yesterday and earned some reputation points.
OAuth is designed for authorization to take actions on your behalf, so that stackoverflow.com (or wherever) can ask permission to, say, Tweet on your behalf automatically, without knowing your Twitter password.

Many people still visit this so here's a very simple diagram to explain it
Courtesy Wikipedia

OAuth
Used for delegated authorization only -- meaning you are authorizing a third-party service access to use personal data, without giving out a password. Also OAuth "sessions" generally live longer than user sessions. Meaning that OAuth is designed to allow authorization
i.e. Flickr uses OAuth to allow third-party services to post and edit a persons picture on their behalf, without them having to give out their flicker username and password.
OpenID
Used to authenticate single sign-on identity. All OpenID is supposed to do is allow an OpenID provider to prove that you say you are. However many sites use identity authentication to provide authorization (however the two can be separated out)
i.e. One shows their passport at the airport to authenticate (or prove) the person's who's name is on the ticket they are using is them.

OpenID is an open standard and decentralized authentication protocol controlled by the OpenID Foundation.
OAuth is an open standard for access delegation.
OpenID Connect (OIDC) Combines the features of OpenID and OAuth i.e. does both Authentication and Authorization.
OpenID take the form of a unique URI managed by some "OpenID provider" i.e identity provider (idP).
OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies.
OIDC uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications. OAuth is directly related to OIDC since OIDC is an authentication layer built on top of OAuth 2.0.
For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google will send back to Auth0 information about the user and the authentication performed. This information is returned in a JSON Web Token (JWT). You'll receive an Access Token and, if requested, an ID Token. Types of Token : Source: OpenID Connect
Analogy:
An organisation use ID card for identification purpose and it contains chips, it stores details about Employee along with Authorization i.e. Campus/Gate/ODC access. ID card act as a OIDC and Chip act as a OAuth. more examples and form wiki

Use OAuth if your users might just want to login with Facebook, or Twitter. Use OpenID if your users are neckbeards that run their own OpenID providers because they "don't want anyone else owning their identity".

The explanation of the difference between OpenID, OAuth, OpenID Connect:
OpenID is a protocol for authentication while OAuth is for
authorization. Authentication is about making sure that the guy you
are talking to is indeed who he claims to be. Authorization is about
deciding what that guy should be allowed to do.
In OpenID, authentication is delegated: server A wants to authenticate
user U, but U's credentials (e.g. U's name and password) are sent to
another server, B, that A trusts (at least, trusts for authenticating
users). Indeed, server B makes sure that U is indeed U, and then tells
to A: "ok, that's the genuine U".
In OAuth, authorization is delegated: entity A obtains from entity B
an "access right" which A can show to server S to be granted access; B
can thus deliver temporary, specific access keys to A without giving
them too much power. You can imagine an OAuth server as the key master
in a big hotel; he gives to employees keys which open the doors of the
rooms that they are supposed to enter, but each key is limited (it
does not give access to all rooms); furthermore, the keys
self-destruct after a few hours.
To some extent, authorization can be abused into some
pseudo-authentication, on the basis that if entity A obtains from B an
access key through OAuth, and shows it to server S, then server S may
infer that B authenticated A before granting the access key. So some
people use OAuth where they should be using OpenID. This schema may or
may not be enlightening; but I think this pseudo-authentication is
more confusing than anything. OpenID Connect does just that: it abuses
OAuth into an authentication protocol. In the hotel analogy: if I
encounter a purported employee and that person shows me that he has a
key which opens my room, then I suppose that this is a true employee,
on the basis that the key master would not have given him a key which
opens my room if he was not.
(source)
How is OpenID Connect different than OpenID 2.0?
OpenID Connect performs many of the same tasks as OpenID 2.0, but does
so in a way that is API-friendly, and usable by native and mobile
applications. OpenID Connect defines optional mechanisms for robust
signing and encryption. Whereas integration of OAuth 1.0a and OpenID
2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
(source)
OpenID connect will give you an access token plus an id token. The id
token is a JWT and contains information about the authenticated user.
It is signed by the identity provider and can be read and verified
without accessing the identity provider.
In addition, OpenID connect standardizes quite a couple things that
oauth2 leaves up to choice. for instance scopes, endpoint discovery,
and dynamic registration of clients.
This makes it easier to write code that lets the user choose between
multiple identity providers.
(source)
Google's OAuth 2.0
Google's OAuth 2.0 APIs can be used for both authentication and
authorization. This document describes our OAuth 2.0 implementation
for authentication, which conforms to the OpenID Connect
specification, and is OpenID Certified. The documentation found in
Using OAuth 2.0 to Access Google APIs also applies to this service. If
you want to explore this protocol interactively, we recommend the
Google OAuth 2.0 Playground.
(source)

OpenID and OAuth are each HTTP-based protocols for authentication and/or authorization. Both are intended to allow users to perform actions without giving authentication credentials or blanket permissions to clients or third parties. While they are similar, and there are proposed standards to use them both together, they are separate protocols.
OpenID is intended for federated authentication. A client accepts an identity assertion from any provider (although clients are free to whitelist or blacklist providers).
OAuth is intended for delegated authorization. A client registers with a provider, which provides authorization tokens which it will accept to perform actions on the user's behalf.
OAuth is currently better suited for authorization, because further interactions after authentication are built into the protocol, but both protocols are evolving. OpenID and its extensions could be used for authorization, and OAuth can be used for authentication, which can be thought of as a no-op authorization.

I believe it makes sense revisit this question as also pointed out in the comments, the introduction of OpenID Connect may have brought more confusion.
OpenID Connect is an authentication protocol like OpenID 1.0/2.0 but it is actually built on top of OAuth 2.0, so you'll get authorization features along with authentication features. The difference between the two is pretty well explained in detail in this (relatively recent, but important) article: http://oauth.net/articles/authentication/

More an extension to the question than an answer, but it may add some perspective to the great technical answers above. I'm an experienced programmer in a number of areas, but a total noob to programming for the web. Now trying to build a web-based application using Zend Framework.
Definitely will implement an application-specific basic username/password authentication interface, but recognize that for a growing number of users the thought of yet another username and password is a deterrent. While not exactly social networking, I know that a very large percentage of the application's potential users already have facebook or twitter accounts. The application doesn't really want or need to access information about the user's account from those sites, it just wants to offer the convenience of not requiring the user to set up new account credentials if they don't want to. From a functionality point of view, that would seem a poster child for OpenID. But it seems that neither facebook nor twitter are OpenID providers as such, though they do support OAuth authentication to access their user's data.
In all the articles I've read about the two and how they differ, it wan't until I saw Karl Anderson's observation above, that "OAuth can be used for authentication, which can be thought of as a no-op authorization" that I saw any explicit confirmation that OAuth was good enough for what I wanted to do.
In fact, when I went to post this "answer", not being a member at the time, I looked long and hard at the bottom of this page at the options for identifying myself. The option for using an OpenID login or obtaining one if I didn't have one, but nothing about twitter or facebook, seemed to suggest that OAuth wasn't adequate for the job. But then I opened another window and looked for the general signup process for stackoverflow - and lo and behold there's a slew of 3rd-party authentication options including facebook and twitter. In the end I decided to use my google id (which is an OpenID) for exactly the reason that I didn't want to grant stackoverflow access to my friends list and anything else facebook likes to share about its users - but at least it's a proof point that OAuth is adequate for the use I had in mind.
It would really be great if someone could either post info or pointers to info about supporting this kind of multiple 3rd-part authorization setup, and how you deal with users that revoke authorization or lose access to their 3rd party site. I also get the impression that my username here identifies a unique stackoverflow account that I could access with basic authentication if I wanted to set it up, and also access this same account through other 3rd-party authenticators (e.g. so that I would be considered logged in to stackoverflow if I was logged in to any of google, facebook, or twitter...). Since this site is doing it, somebody here probably has some pretty good insight on the subject. :-)
Sorry this was so long, and more a question than an answer - but Karl's remark made it seem like the most appropriate place to post amidst the volume of threads on OAuth and OpenID. If there's a better place for this that I didn't find, I apologize in advance, I did try.

After reading and doing some work, I figured the things I needed to know, these are: OpenID Connect, OAuth, JWT and SAML.
I will give a summary, it might help someone:
OpenID Connect (OIDC): If we can login a website using google account, then you are using OIDC.
OAuth: an application wants to access my facebook contact list and do some stuff on my behalf. If I authorise this application, then probably I am using OAuth.
JWT: OAuth uses JWT, JWT (JSON Web Tokens)- It is just a token format. JWT tokens are JSON encoded data structures contains information about issuer, subject (claims), expiration time etc. It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).
Authorization flow in OAuth:
OAuth 2.0 protocol provides several workflows for authorizing a user and obtaining an access token. It depends on the type and architecture of the client which flow is the most suitable.
Below are 2 most used Authorizations flows:
Authorization Code: Suitable for third-party websites which contain a client and a server component.
The user enters credentials to a secure login webpage.
After logging in, the browser is redirected to a special URL (defined by the client), passing an authorization code in the URL.
The third-party server obtains the access token with another HTTP request in the background, using the authorization code.
From https://developers.video.ibm.com/api-basics-authentication/
Note: if you have a frontend application and the server sets a cookie in the browser, then you already have the cookie in your browser and can accees the website.
Client Credentials: Best choice for users developing server-side applications to manage their content or settings.
IBM has a good guide here: https://developers.video.ibm.com/api-basics-authentication
To know all other flows with pros and cons: here: https://www.geeksforgeeks.org/workflow-of-oauth-2-0/
SAML: Also used as an alternative of openid, but it is xml based. because developers find OIDC much easier to work with and because it is more flexible (e.g. working with mobile app is easier than xml based SAML), OIDC looks like it will become the winner.
OpenID Connect (OIDC) vs SAML: there are main differences:
SAML transmits user data in XML format. OIDC transmits user data in JSON format.
SAML calls the user data it sends a SAML Assertion. OIDC calls the
data Claims.
SAML calls the application or system the user is trying to get into
the Service Provider. OIDC calls it the Relying Party.
SAML is old, has more features, but OpenID is gaining more popularity as it is easier to implement, easier to use than XML based SAML
But not all identity providers support OpenID or SAML, if the identity provider you want to integrate only supports SAML, then you have no choice.
Want more OpenID vs SAML? read below:
https://www.onelogin.com/blog/real-difference-saml-oidc
https://auth0.com/intro-to-iam/saml-vs-openid-connect-oidc/
Want more? You can read this OAuth and OpenID analogy:
http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/

OpenID proves who you are.
OAuth grants access to the features provided by the authorizing party.

I am currently working on OAuth 2.0 and OpenID connect spec. So here is my understanding:
Earlier they were:
OpenID was proprietary implementation of Google allowing third party applications like for newspaper websites you can login using google and comment on an article and so on other usecases. So essentially, no password sharing to newspaper website. Let me put up a definition here, this approach in enterprise approach is called Federation. In Federation, You have a server where you authenticate and authorize (called IDP, Identity Provider) and generally the keeper of User credentials. the client application where you have business is called SP or Service Provider. If we go back to same newspaper website example then newspaper website is SP here and Google is IDP. In enterprise this problem was earlier solved using SAML. that time XML used to rule the software industry. So from webservices to configuration, everything used to go to XML so we have SAML, a complete Federation protocol
OAuth: OAuth saw it's emergence as an standard looking at all these kind of proprietary approaches and so we had OAuth 1.o as standard but addressing only authorization. Not many people noticed but it kind of started picking up. Then we had OAuth 2.0 in 2012. CTOs, Architects really started paying attention as world is moving towards Cloud computing and with computing devices moving towards mobile and other such devices. OAuth kind of looked upon as solving major problem where software customers might give IDP Service to one company and have many services from different vendors like salesforce, SAP, etc. So integration here really looks like federation scenario bit one big problem, using SAML is costly so let's explore OAuth 2.o. Ohh, missed one important point that during this time, Google sensed that OAuth actually doesn't address Authentication, how will IDP give user data to SP (which is actually wonderfully addressed in SAML) and with other loose ends like:
a. OAuth 2.o doesn't clearly say, how client registration will happen
b. it doesn't mention anything about the interaction between SP (Resource Server) and client application (like Analytics Server providing data is Resource Server and application displaying that data is Client)
There are already wonderful answers given here technically, I thought of giving of giving brief evolution perspective

Nowadays OpenID connect is most relevant so I will explain the difference between OpenID connect and OAuth 2.
OpenID connect specifies the IDToken standard: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
This is the primary contribution of OpenID connect. So it specifies what should be contained in the response after authentication is complete.
The IDToken needs to be a JWT token, and contains information of the user, such as user id, user name, etc. The information returned depends on the claims passed when authorizing. It also contains an expiration date of the token and it should contain the digital signature of the token. This signature is used to validate the token using a public key.
The second big difference is related to the public key. OpenID connect uses something called discovery or well known endpoint. It's an endpoint that is publicly open and just returns a JSON with values such as the public key and authorization endpoints.
https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedDiscovery
So essentially OpenID is related to authentication since it specifies the IDToken, which is necessary to authenticate a user by checking the digital signature and expiration date of the IDToken.
OAuth deals with authorization especially related to scopes and validating access tokens on the resource server.
However as written here, OpenID uses OAuth 2 authorization for authentication.
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
An Authentication Request is an OAuth 2.0 Authorization Request that requests that the End-User be authenticated by the Authorization Server.
In short, try to think of OpenID as authentication using the JWT token and OAuth as authorization with scopes.

I'd like to address a particular aspect of this question, as captured in this comment:
OAuth: before granting access to some feature, authentication must be done, right ?. so OAuth = what OpenId does + grants access to some features ? – Hassan Makarov Jun 21 at 1:57
Yes... and no. The answer is subtle, so bear with me.
When the OAuth flow redirects you to a target service (the OAuth provider, that is), it is likely that you'll need to authenticate with that service before a token will be handed back to the client application/service. The resulting token then allows the client app to make requests on behalf of a given user.
Note the generality of that last sentence: specifically, I wrote "on behalf of a given user", not "on behalf of you". It's a common error to assume that "having a capability to interact with a resource owned by a given user" implies "you and the owner of the target resource(s) are one in the same".
Don't make this mistake.
While it's true that you authenticate with the OAuth provider (say, by user name and password, or maybe SSL client certs, or some other means), what the client gets in return should not necessarily be taken as proof of identity. An example would be a flow in which access to another user's resources was delegated to you (and by proxy, the OAuth client). Authorization does not imply authentication.
To handle authentication, you'll likely want to look into OpenID Connect, which is essentially another layer on top of the foundation set by OAuth 2.0. Here's a quote that captures (in my opinion) the most salient points regarding OpenID Connect (from https://oauth.net/articles/authentication/):
OpenID Connect is an open standard published in early 2014 that defines an interoperable way to use OAuth 2.0 to perform user authentication. In essence, it is a widely published recipe for chocolate fudge that has been tried and tested by a wide number and variety of experts. Instead of building a different protocol to each potential identity provider, an application can speak one protocol to as many providers as they want to work with. Since it's an open standard, OpenID Connect can be implemented by anyone without restriction or intellectual property concerns.
OpenID Connect is built directly on OAuth 2.0 and in most cases is deployed right along with (or on top of) an OAuth infrastructure. OpenID Connect also uses the JSON Object Signing And Encryption (JOSE) suite of specifications for carrying signed and encrypted information around in different places. In fact, an OAuth 2.0 deployment with JOSE capabilities is already a long way to defining a fully compliant OpenID Connect system, and the delta between the two is relatively small. But that delta makes a big difference, and OpenID Connect manages to avoid many of the pitfalls discussed above by adding several key components to the OAuth base: [...]
The document then goes on to describe (among other things) token IDs and a UserInfo endpoint. The former provides a set of claims (who you are, when the token was issued, etc, and possibly a signature to verify the authenticity of the token via a published public key without having to ask the upstream service), and the latter provides a means of e.g. asking for the user's first/last name, email, and similar bits of info, all in a standardized way (as opposed to the ad-hoc extensions to OAuth that people used before OpenID Connect standardized things).

Both protocols were created for different reasons. OAuth was created to authorize third parties to access resources. OpenID was created to perform decentralize identity validation. This website states the following:
OAuth is a protocol designed to verify the identity of an end-user and to grant permissions to a third party. This verification results in a token. The third party can use this token to access resources on the user’s behalf. Tokens have a scope. The scope is used to verify whether a resource is accessible to a user, or not
OpenID is a protocol used for decentralised authentication. Authentication is about identity; Establishing the user is in fact the person who he claims to be. Decentralising that, means this service is unaware of the existence of any resources or applications that need to be protected. That’s the key difference between OAuth and OpenID.

OAuth gives you back the access token to access the resource from resource server, OpenID gives you back meta data details about resources in JWT / encrypted token

OpenId uses OAuth to deal with authentication.
By analogy, it's like .NET relies on Windows API. You could directly call Windows API but it's so wide, complex and method arguments so vast, you could easily make mistakes/bugs/security issue.
Same with OpenId/OAuth. OpenId relies on OAuth to manage Authentication but defining a specific Token (Id_token), digital signature and particular flows.

OpenId - Used only for Authentication.
OAuth - Used for both Authentication and Authorization. Authorization depends on the access_token which comes as part of JWT token. It can have details of user permissions or any useful information.
Both can rely on 3rd party auth provider which maintains their accounts. For example OKTA identity provider, User provides the credentials on OKTA login page and on successful login the user is redirected on the consumer application with the JWT token in the header.

OAuth 2.0 is a Security protocol. It is NEITHER an Authentication NOR an Authorization protocol.
Authentication by definition the answers two questions.
Who is the user?
Is the user currently present on the system?
OAuth 2.0 has the following grant types
client_credentials: When one app needs to interact with another app and modify the data of multiple users.
authorization_code: User delegates the Authorization server to issue an access_token that the client can use to access protected resource
refresh_token: When the access_token expires, the refresh token can be leveraged to get a fresh access_token
password: User provides their login credentials to a client that calls the Authorization server and receives an access_token
All 4 have one thing in common, access_token, an artifact that can be used to access protected resource.
The access_token does not provide the answer to the 2 questions that an "Authentication" protocol must answer.
An example to explain Oauth 2.0 (credits: OAuth 2 in Action, Manning publications)
Let's talk about chocolate. We can make many confections out of chocolate including, fudge, ice cream, and cake. But, none of these can be equated to chocolate because multiple other ingredients such as cream and bread are needed to make the confection, even though chocolate sounds like the main ingredient. Similarly, OAuth 2.0 is the chocolate, and cookies, TLS infrastucture, Identity Providers are other ingredients that are required to provide the "Authentication" functionality.
If you want Authentication, you may go for OpenID Connect, which provides an "id_token", apart from an access_token, that answers the questions that every authentication protocol must answer.

OAuth builds authentication on top of authorization: The user delegates access to their identity to the application, which, then, becomes a consumer of the identity API, thereby finding out who authorized the client in the first place http://oauth.net/articles/authentication/