Difference between OAuth , Open ID , OpenID Connect, SAML

To understand the difference lets have a look at the following scenario for each.

OpenID scenario

1. Sam wants to access his account on Spotify.
2. Spotify (the Relying party) asks Sam for his OpenID Facebook log in details
3. Sam clicks on Facebook login details
4. Spotify redirects Sam to OpenID Provider Facebook
5. Sam authenticates himself to the Facebook
6. Facebook redirects Sam back to Spotify
7. Spotify allows Sam to access his account.

OAuth Scenario

1. Sam (the end user) is on Linkedin and wants to import his contacts from Google
2. Linkedin (the consumer, the client)  requests for Request Token and Secret Key from Google (the resource server or provider) 
3. Google issues Request Token and Secret Key
4. LinkedIn asks Sam for authorization and passes a link that contains the Request Token
5. Sam clicks on the URL containing the Request Token, the API call passes the secret key and Sam authenticates himself to Google
6. Google asks Sam whether he wants to authorize LinkedIn to access his contacts
7. Sam makes his choice
8. Google generates an Access Token and an Access Token secret and forwards Sam   back to LinkedIn
9. LinkedIn retrieves the contacts from Google by including the Access Token and Access Token Secret
10. LinkedIn informs the user that the import was successful.

From these scenarios, we can say that Open ID is authentication protocol and OAuth is Authorisation protocol. They both use “access tokens” that contain scopes and claims .

Open ID gives you one login for multiple sites whereas  With OAuth, you still need to log into the provider. 
OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have whereas 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).

How does OpenID work

OpenID is a protocol used for decentralized authentication. Authentication is about identity, that is, establishing that the user is, in fact, the person who he or she claims to be. Decentralizing 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.

In simple words, a country issues its national with a passport after verifying the identity. The passport can be used in multiple situations as an ID. The passport doesn't say anything about permissions. In 2007 Microsoft pledged to support OpenID. Microsoft embedded OpenID into their software, which manifested in the claims-identity in ASP.NET.

OpenID protocol is deprecated in favor of OpenIDConnect.

How  does OAuth work

OAuth is an authorization protocol used to protect resources.  OAuth is a protocol designed to verify the identity of an end-user and 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. 

In simpler words, an access token is like the boarding pass you get when you check in for your flight. The person at the counter verifies your identity, and based on your booking, you receive the boarding pass that allows you to board on to your flight. When you present the access token to the door, it validates your credentials and allows you to enter.

The OAuth specifications define the following roles:

• The end user or the entity that owns the resource in question

• The resource server (OAuth Provider), which is the entity hosting the resource

• The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

What is OpenID Connect protocol?

This is an extension over OAuth 2.0 authorization framework. OpenID connect allows authentication and authorization. Unlike OAuth 2.0, OpenID Connect issue ID token. ID Token contains end user details in JWT format. Thus the ID token receiving client can validate the token and authenticate the end user.  OpenID Connect specifies a RESTful HTTP API, using JSON as a data format. 

ID token is sent along with OAuth 2.0 access token. Access tokens are used to get authorized against OAuth 2.0 protected endpoints.

The OpenID Connect specification defines three roles:

• The end user or the entity that is looking to verify its identity
• The relying party (RP), which is the entity looking to verify the identity of the end user
• The OpenID Connect provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity.

 What is SAML Protocol?

Security Assertion Markup Language (SAML) is  an XML-based open standard for exchanging authentication and authorization data between parties.

The SAML specification defines three roles:

• The principal, which is typically the user looking to verify his or her identity
• The identity provider (idP), which is the entity  that is capable of verifying the identity of the end user
• The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

Scenario

1. Sam tries to access a hosted corporate application (the Service Provider)
2. Service Provider generates SAML request and redirects browser to the Identity Provider.
3. Sam is redirected to the Identity provider together with the SAML request.
4. Identity provider authenticates Sam , parses SAML request and generates SAML response 
5. Browser sends SAML response to the service provider
6. Service provider verifies SAML response and Sam logs in.

	OpenID	OAuth
Dates From	2005	2006	2001
Current version	OpenID 2.0	OAuth 2.0	SAML 2.0
Main Purpose	Single Sign-On for Consumers	API Authorization Between Applications	Single Sign-On for Enterprise Users
Protocols Used	XRDS, HTTP	JSON, HTTP	SAM, XML, HTTP, SOAP

In SAML, the user is redirected from the Service Provider (SP) to the Identity Provider (IDP) for sign in.

In OpenID Connect, the user is redirected from the Relying Party (RP) to the OpenID Provider (OP) for sign in.

The SAML SP is always a website. The OpenID Connect RP is either a web or mobile application, and is frequently called the “client” because it extends an OAuth 2.0 client.

In both cases, the IDP/OP controls the login to avoid exposing secrets (like passwords) to the website or app.

In SAML, there is an “assertion”–a signed XML document with the subject information (who authenticated), attributes (info about the person), the issuer (who issued the assertion), and other information about the authentication event.

The equivalent in OpenID Connect is the id_token. This is a signed JSON document that contains the subject, issuer, and authentication information.

So when should SAML be used, and when should OAuth 2.0 or OpenID Connect be used instead?

• Mobile applications: no question–use OpenID Connect.
• If the application already supports SAML: use SAML.
• If you are writing a new application, use OpenID Connect