What is the difference between OAuth based and Token based authentication? - authentication

I thought that OAuth is basically a token based authentication specification but most of the time frameworks act as if there is a difference between them. For example, as shown in the picture below Jhipster asks whether to use an OAuth based or a token based authentication.
Aren't these the same thing ? What exactly is the difference since both includes tokens in their implementations ?


This is a good question -- there is a lot of confusion around tokens and OAuth.
First up, when you mention OAuth, you are likely referring to the OAuth2 standard. This is the latest version of the OAuth protocol, and is what most people are specifically talking about when they say 'OAuth'.
The OAuth protocol supports several different types of authentication and authorization (4 to be precise).
Secondly, the OAuth protocol works by authenticating users via tokens. The idea here is this:
Instead of having your user send their actual credentials to your server on every single request (like they would with Basic Auth, where a user sends their username/password to the server for each request), with OAuth you first exchange your user credentials for a 'token', and then authenticate users based on this 'token'.
The idea of OAuth is that by requiring users to pass their confidential credentials over the network less frequently, less bad things can happen. (This is the idea, anyhow.)
Now, here's where tokens come into play: the OAuth spec is built around the concept of tokens, but DOES NOT SPECIFY WHAT A TOKEN IS.
In the most 'general' sense, a token is just a string that uniquely identifies a user. That's it.
People realized this, and developed a new standard for creating tokens, called the JSON Web Token standard. This standard basically provides a set of rules for creating tokens in a very specific way, which makes tokens more useful for you in general.
JWTs let you do things like:
Cryptographically sign a token so you know that a token wasn't tampered with by a user.
Encrypt tokens so the contents cannot be read in plain text.
Embed JSON data INSIDE of a token string in a standard way.
Now, for the most part: pretty much everyone in the development community has agreed that if you're using any sort of OAuth, then the tokens you're using should be JSON Web Tokens.
OK! Now that we've covered the backstory, let me answer your question.
The choice you're making above is whether or not you want to enable the full OAuth2 specification for authentication / authorization (which is quite complex), or whether you simply want some basic 'token authentication'.
Because the OAuth protocol provides multiple different ways to authenticate in a STANDARDS COMPLIANT way, it adds a lot of complexity to most authentication systems.
Because of this, a lot of frameworks offer a 'dumbed down' version of the OAuth2 Password Grant flow, which essentially is a simple method where:
A user sends their username/password to your server at some URL like /login.
Your server generates a JWT token for the user.
Your server returns that token to the user.
The user stores this token in their cookies, mobile device, or possible API server, where they use it to make requests.
Again: the flow above is NOT OAuth compliant, but is a slightly simpler version that STILL uses tokens.
The main point here is that tokens (JWTs) are generally useful, and don't NEED to be paired with the OAuth flow.
I realize this is a wall of text, but hopefully it answers your question in more depth =)


OAuth is a specification for authorization not authentication
OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:
The authorization endpoint is used to interact with the resource owner
and obtain an authorization grant. The authorization server MUST first
verify the identity of the resource owner. The way in which the
authorization server authenticates the resource owner (e.g., username
and password login, session cookies) is beyond the scope of this
specification.
Only use OAuth if you want to give access to a third party service to your apis. Even when you are using OAuth you would need some kind of authentication (token based or session based etc) to authenticate the uses. OAuth is not designed for authentication.
see this question.


When you are requesting resource from a secured web service, you can provide an authentication token on the call. The token acts as "secret code" for accessing the resource.
OAuth is just specific type of token based authentication method.

Related

Bearer token out of an OAUTH setting - question about correct use of standards

The IANA registry of Authentication schemes (http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml) states that the Bearer authentication scheme is defined in the context of the Oauth protocol.
Does it make sense using a bearer token without an OAuth setting?
For example: I want to call an API of another company; we agree on a custom scheme for a JWT security token to add to an API call (for example, suppose you don't use an Authorization Server as OAUTH would require, we use another custom mechanism). The JWT is signed and encoded and added to an API call using the Authorization http header with a bearer authentication scheme.
The question is not if this can work, because I know it can and it is good enough from a security point of view (this is why I don't add much details about the real implementation).
My question is about use of the standards: from a formal point of view are we right if we declare a bearer token outside of an Oauth setting?
A second question could be: would it be possible to declare a custom authentication scheme, for example 'myBearer'?
Thank You,
Corrado Tamietti

I would recommend following a standard pattern for your B2B security. Usually this involves an Authorization Server, but if there isn't one, for reasons out of your control, then using tokens can still be useful, in order to:
Communicate scopes to represent areas of data
Communicate claims used for finer grained authorization rules
I would design a solution around the following rules:
Company B, who own the API, must issue the access tokens. Only they should have access to the private key used to issue them. They can then control privileges, time to live and other aspects.
Company A have to call a Company B endpoint to get an access token, which involves sending a credential. The token received should be fairly confidential and not contain sensitive data.
Company A then sends that access token to other Company B endpoints to access data.
Even if you keep OAuth behaviour light for the time being, this is a standard pattern that should fit nicely into your applications and support future extensibility.
USE OF AUTHORIZATION HEADER
The link you provided referenced OAuth 1.0, which used the OAUTH keyword
in the Authorization header - but very few people use OAuth v1 these days, partly because it is less web / mobile friendly than OAuth v2.
OAuth v2 best practice involves sending JWTs via the general HTTP mechanism of the Authorization header - see this section from the draft OAuth 2.1 spec.
If you are using standard JWTs (without more advanced features such as proof of possession) then using 'bearer' feels like the right option to me. This describes only how the API message credential is presented and does not have to mean that a full OAuth solution is in place.
FURTHER DETAILS ON AUTHORIZATION AND B2B
OAuth B2B APIs usually use the Client Credentials Grant, and if data sensitivity is high, step 2 often involves use of Mutual TLS. Here are some related links from the Curity Web Site:
Scopes in APIs
Claims in APIs
Financial Grade B2B APIs

What are the main differences between JWT and OAuth authentication?

I have a new SPA with a stateless authentication model using JWT. I am often asked to refer OAuth for authentication flows like asking me to send 'Bearer tokens' for every request instead of a simple token header but I do think that OAuth is a lot more complex than a simple JWT based authentication. What are the main differences, should I make the JWT authentication behave like OAuth?
I am also using the JWT as my XSRF-TOKEN to prevent XSRF but I am being asked to keep them separate? Should I keep them separate? Any help here will be appreciated and might lead to a set of guidelines for the community.

TL;DR
If you have very simple scenarios, like a single client application, a single API then it might not pay off to go OAuth 2.0. On the other hand, if there are lots of different clients (browser-based, native mobile, server-side, etc) then sticking to OAuth 2.0 rules might make it more manageable than trying to roll your own system.
As stated in another answer, JWT (Learn JSON Web Tokens) is just a token format. It defines a compact and self-contained mechanism for transmitting data between parties in a way that can be verified and trusted because it is digitally signed. Additionally, the encoding rules of a JWT also make these tokens very easy to use within the context of HTTP.
Being self-contained (the actual token contains information about a given subject), they are also a good choice for implementing stateless authentication mechanisms (aka Look mum, no sessions!). When going this route, the only thing a party must present to be granted access to a protected resource is the token itself, and the token in question can be called a bearer token.
In practice, what you're doing can already be classified as bearer token -based. However, do consider you're not using bearer tokens as specified by the OAuth 2.0 related specs (see RFC 6750). That would imply relying on the Authorization HTTP header and using the Bearer authentication scheme.
Regarding the use of the JWT to prevent CSRF: Without knowing exact details it's difficult to ascertain the validity of that practice. To be honest, it does not seem correct and/or worthwhile. The following article (Cookies vs Tokens: The Definitive Guide) may be a useful read on this subject, particularly the XSS and XSRF Protection section.
One final piece of advice. Even if you don't need to go full OAuth 2.0, I would strongly recommend on passing your access token within the Authorization header instead of going with custom headers. If they are really bearer tokens, follow the rules of RFC 6750. If not, you can always create a custom authentication scheme and still use that header.
Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers.
(source: RFC 6819, section 5.4.1)

OAuth 2.0 defines a protocol, i.e. specifies how tokens are transferred, JWT defines a token format.
OAuth 2.0 and "JWT authentication" have similar appearance when it comes to the (2nd) stage where the Client presents the token to the Resource Server: the token is passed in a header.
But "JWT authentication" is not a standard and does not specify how the Client obtains the token in the first place (the 1st stage). That is where the perceived complexity of OAuth comes from: it also defines various ways in which the Client can obtain an access token from something that is called an Authorization Server.
So the real difference is that JWT is just a token format, OAuth 2.0 is a protocol (that may use a JWT as a token format).

Firstly, we have to differentiate JWT and OAuth. Basically, JWT is a token format. OAuth is an authorization protocol that can use JWT as a token. OAuth uses server-side and client-side storage. If you want to do real logout you must go with OAuth2. Authentication with JWT token can not logout actually. Because you don't have an Authentication Server that keeps track of tokens. If you want to provide an API to 3rd party clients, you must use OAuth2 also. OAuth2 is very flexible. JWT implementation is very easy and does not take long to implement. If your application needs this sort of flexibility, you should go with OAuth2. But if you don't need this use-case scenario, implementing OAuth2 is a waste of time.
XSRF token is always sent to the client in every response header. It does not matter if a CSRF token is sent in a JWT token or not, because the CSRF token is secured with itself. Therefore sending CSRF token in JWT is unnecessary.

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).
OAuth2 - OAuth2 solve a problem that user wants to access the data using client software like browse based web apps, native mobile apps or desktop apps. OAuth2 is just for authorization, client software can be authorized to access the resources on-behalf of end user using access token.
OpenID Connect - OpenID Connect builds on top of OAuth2 and add authentication. OpenID Connect add some constraint to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers and session management. JWT is the mandatory format for the token.
CSRF protection - You don't need implement the CSRF protection if you do not store token in the browser's cookie.

It looks like everybody who answered here missed the moot point of OAUTH
From Wikipedia
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.[1] This mechanism is used by companies such as Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.
The key point here is access delegation. Why would anyone create OAUTH when there is an id/pwd based authentication, backed by multifactored auth like OTPs and further can be secured by JWTs which are used to secure the access to the paths (like scopes in OAUTH) and set the expiry of the access
There's no point of using OAUTH if consumers access their resources(your end points) only through their trusted websites(or apps) which are your again hosted on your end points
You can go OAUTH authentication only if you are an OAUTH provider in the cases where the resource owners (users) want to access their(your) resources (end-points) via a third-party client(external app). And it is exactly created for the same purpose though you can abuse it in general
Another important note:
You're freely using the word authentication for JWT and OAUTH but neither provide the authentication mechanism. Yes one is a token mechanism and the other is protocol but once authenticated they are only used for authorization (access management). You've to back OAUTH either with OPENID type authentication or your own client credentials

find the main differences between JWT & OAuth
OAuth 2.0 defines a protocol & JWT defines a token format.
OAuth can use either JWT as a token format or access token which is a bearer token.
OpenID connect mostly use JWT as a token format.

JWT is an open standard that defines a compact and self-contained way for securely transmitting information between parties. It is an authentication protocol where we allow encoded claims (tokens) to be transferred between two parties (client and server) and the token is issued upon the identification of a client. With each subsequent request we send the token.
Whereas OAuth2 is an authorization framework, where it has a general procedures and setups defined by the framework. JWT can be used as a mechanism inside OAuth2.
You can read more on this here
OAuth or JWT? Which one to use and why?

Jwt is a strict set of instructions for the issuing and validating of signed access tokens. The tokens contain claims that are used by an app to limit access to a user
OAuth2 on the other hand is not a protocol, its a delegated authorization framework. think very detailed guideline, for letting users and applications authorize specific permissions to other applications in both private and public settings. OpenID Connect which sits on top of OAUTH2 gives you Authentication and Authorization.it details how multiple different roles, users in your system, server side apps like an API, and clients such as websites or native mobile apps, can authenticate with each othe
Note oauth2 can work with jwt , flexible implementation, extandable to different applications

JWT tokens require, at most, a one-time communication between the resource server and the authorization server at runtime. The
resource server needs to request the authorization server for the
public key to decrypt the JWT tokens. This can be done at resource
server startup. This can even be stored in the resource server in a
properties file avoiding the query at all.
OAuth2 solve a problem that user wants to access the data using client software like browser-based web apps, native mobile apps, or
desktop apps. OAuth2 is just for authorization, client software can
be authorized to access the resources on behalf of end-user using an
access token.
OAuth2 can be used with JWT tokens or access token which is a bearer
token.

Architecturing API keys and access tokens

I have a question regarding how I should architecture a REST API using access token and API keys.
I have an API that needs authentication. I want to enable two use cases:
The user logs into the interface using OAuth2 (password grant), and is granted a temporary access token. This token is used to authenticate the user. Therefore, the UI, that itself using the API, can fetch data and display it.
I also want the user to have an API key to do the same calls, but in its application. Obviously, contrary to the access token, I want the API key to be long lived. Also, contrary to the access token that is tied to a given user (if we introduce a team mechanism, each user will have different access token, although they access the same resources), the API key should be unique to the project.
While similar, I'm not sure about how should I architecture that. I think that, internally, both API keys and access tokens should be stored in the same table, but API keys having no expiration time. Am I right?
One thing I'm not sure also is the concept of client. It seems that in the spec, the client is more like an external application. However may I actually use this concept here?
For instance, each "project" is actually a different client (although the client here is the same application, not an application created by a third-party developer).
Therefore, if user A creates an account on the system, a client A will be automatically created, with an access token tied to the client A, with a long-lived access token (aka API key). This can be used to perform API calls directly on his code, for instance.
Then, if user A logs into the dashboard, a temporary access token will be created, but this time with no application, but tied to the user, with a short life.
Does this sound sane? Have anyone already implemented such a thing?
Thanks!

I think you should not consider the "API keys" a substitute of the access token.
You will have to use an access token anyway to bear the authentication between requests, so what you're actually modelling with your "API keys" is not a replacement of the usual bearer token, but rather a different client that provides other grant types to request a token with.
The flow I'd personally implement is the following:
The user authenticates with the password grant type with a common client for every user (i.e. your "web app" client, which is public, i.e. it doesn't have a client_secret).
The user can then create its own client. As per OAuth2 specs, these are not public, so they will consists of a client_id and a client_secret. These are what you call "API keys".
A user will then be able to request an access token via their client, with any given grant type you want to support (e.g. direct client credentials, authorization code, implicit, third parties, etc.). You will have to stress quite a bit about the due safety practices on how to handle the client credentials.
Obviously, you will have to implement your OAuth2 server in such a way that clients can belong specific users, and have different acceptable grant types (i.e. you may not want to allow the password grant usage with a user client, while you may want to disallow any grant type other than the password one for your web app client).
You will then be able to define tokens TTLs, or lack thereof, on a per client or per grant type basis (e.g. access token requested via password grant, only usable by web app client, will have a short TTL, while authorization code grant will provide long lived tokens).
I would advise against complete lack of TTL, though, and rather use the refresh_token grant type to renew expired access tokens.
Furthermore, you'll probably have to define an authorization system of some some sort (ACL, RBAC, whatever), to define which client can do what. This means each access token should contain a reference to the client used for its creation.
So, to sum it up, here are the relations:
User has a Client.
Client has a User.
Client has many Token.
Token has a Client.
Token has a User.
YMMV on bidirectionals.
You should be able to implement everything I described with the most common OAuth2 servers implementations of any given platform.
TL;DR: "API keys" are actually OAuth2 clients.

I wrote a post about the way to use access tokens for RESTful applications: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/. Perhaps can this give some hints.
To answer your questions, I think that we need to have something homogeneous. I mean all your authentication mechanisms should be based on access tokens. Your API keys would allow you to get an access token that would be actually used for authentication.
As far as I understand, you have two kinds of users of your applications:
End-users using the Web UI (login with password through OAuth2)
Applications (login with API keys)
So I would implement these two kinds of users and make them the ability to get access tokens. Access tokens will be used in both cases to access the RESTful services.
In addition, I think that this answer can give you some other hints: Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth).
Hope it answers your question.
Thierry

Thank you for your answer.
I'm actually quite experience with OAuth2 itself, my question was more targeted to API keys. I like the idea of an API key exchanging an access token but I think that does not work. The API key is fixed and does not change, while the access token can expires.
The question is: how the app can know if this is an access token or API keys. I mean, ok, let's say that in my database, each user has an "api_key" column in their database.
Contrary to an access token, the api_key does not expires (although the user can eventually rotate it). What I want, as I told, is homogeneous handling of authentication.
Case 1: my own web app do API calls
The workflow is as follow, using OAuth2:
User enters his mail/password.
Authorization server returns a temporary access token (eg.: "abc").
In the web app, all API calls are done using this token. For instance: "/payments/1" with Authorization header: "Bearer abc".
Nice and simple.
Case 2: the user has an API key, that does not expire and can be used privately in their own app
Obviously, the authorization mechanism must stay the same. So:
User goes into his account, and read that his API key is "def".
In their server code, they can do the same call, with same authentication mechanism. So he can call "/payments/1" with Authorization: "Bearer def".
And it must work. As you can see, nothing has changed in both examples. They access the same resource, same authorization mechanism... but in one case we have an access token and in other case we have an API key. And I have no idea how I should implement that both from a database point of view and in the authorization code.
One potential idea I had is using different auth mechanism. For OAuth, it would be "Authorization: Bearer accessToken", while for API it would be a Basic authentication: "Authorization: Basic apiKey".
Does this sound good?

RESTful API security

I would like to develop RESTful API for my web application. Client have to be clear JS + HTML and user have to somehow authenticate in system. I've read few articles about security and RESTful API but some point still are not clear for me. As I've understood at the first step user have to provide his credentials to server. After that server have to validate user credentials and if they are valid, sent some encoded token to user (assume it will be [user key]:[user IP]:[token creation time]). After user authentication client have to sent this this key with each API call. That's how I've understood RESTful API authentication principes.
With such solution I assume that token can be stolen and another user can access to secured user data (even if IP is included to access token and there will be validation on each request). For this purpose I plan to include token creation time but as I understand with such solution I have to renew access token each time when it expiring - in this case it's not clear for me how to implement "remember me" functionality.
It's not clear for me how to implement 100% safe authentication for my RESTful API. Maybe I'm missing something. Or maybe my understanding of authentication principes is wrong.

It depends from what authentication scenario you are using. For example when dealing with in ASP.NET MVC + REST with Basic Authentication it will produce for you token which is in the fact Base64 encoded string '{username}:{password}'. And you are right it could be stolen, that's why for Basic Auth HTTPS is must, as token goes throw Authentication header with Basic schema.
For REST security most suitable and secure are OpenId and OAuth. Just don't reinvent wheel and use already existing standards. OAuth in compare to OpenID includes not only authentication but authorization as well. OAuth already describes all nuances with token renew and token creation time and so on.
Now practical how to implement OAuth in REST. First of all read standard. For your case read with attention Implicit Grant flow, because standard has multiple flows for different client with different trust level and security.
https://www.rfc-editor.org/rfc/rfc6749
And after that you can try some already implemented library in technological stack you are using either Java or .NET. For client it is not so important to use library in compare but for server implementation
About potential security problem read here https://www.rfc-editor.org/rfc/rfc6749#section-10.
Some think that OAuth 2.0 is less secure that OAuth 1.0, and it is also dependant from token format. Anyway access token should be passed in HTTP Header and through HTTPS as well as clientid should be stored and passed securely.

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/