What's the difference between OpenID and OAuth?

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.

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.

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".

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:

1. 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.

2. 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:

1. SAML transmits user data in XML format. OIDC transmits user data in JSON format.

2. SAML calls the user data it sends a SAML Assertion. OIDC calls the data Claims.

3. SAML calls the application or system the user is trying to get into the Service Provider. OIDC calls it the Relying Party.

4. 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/

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

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 reruns 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.

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.

1. Who is the user?
2. 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.