Key Points

1. OpenId is an authentication only solution
2. OpenId is authentication only, can use OAuth2 for authorization
3. OpenId Connect is current version
4. Openid Connect ( OIDC ) can interface with DIDs for authentication
5. OAuth2 implementations provide both authentication and authorization
6. OAuth2 can grant more authority to an application than needed to authenticate an identity
7. Pure identity providers only authenticate an identity to a client application for a purpose based on a request from a principal ( an entity or user )

References

Key Concepts

OpenID and OAuth2 use cases

OpenID for authentication

OAuth2 for delegated authorization

OAuth2

https://en.wikipedia.org/wiki/OAuth

OAuth can be used as an authorizing mechanism to consume secured RSS/ATOM feeds. Consumption of RSS/ATOM feeds that require authentication has always been an issue. For example, an RSS feed from a secured Google Site could not have been consumed using Google Reader. Instead, three-legged OAuth would have been used to authorize that RSS client to access the feed from the Google Site. It can also be used as a means to login without creating an account on any site and all the benefits of the host of the OAuth system.

OpenID

OpenID is for authentication only

OpenID with OAuth Delegated Resource Access

OpenID vs. pseudo-authentication using OAuth

OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication.^{[citation needed]} The following diagrams highlight the differences between using OpenID (specifically designed as an authentication protocol) and OAuth for authentication.

The communication flow in both processes is similar:

1. (Not pictured) The user requests a resource or site login from the application.
2. The site sees that the user is not authenticated. It formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
3. The user's browser requests the redirect URL for the identity provider, including the application's request
4. If necessary, the identity provider authenticates the user (perhaps by asking them for their username and password)
5. Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
6. The user's browser requests the redirect URL that goes back to the application, including the identity provider's response
7. The application decodes the identity provider's response, and carries on accordingly.
8. (OAuth only) The response includes an access token which the application can use to gain direct access to the identity provider's services on the user's behalf.

The crucial difference is that in the OpenID authentication use case, the response from the identity provider is an assertion of identity; while in the OAuth authorization use case, the identity provider is also an API p

OpenId vs OAuth2 - comparison flows for authentication

https://en.wikipedia.org/wiki/OAuth#/media/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

Compare OAuth2 and OIDC

compare oauth2 and oidc - 2022 **

OAuth_and_OpenID_Connect_in_plain_English_v1.6__KCDC_.pdf file

Potential Value Opportunities

OpenId for Authentication 

https://en.wikipedia.org/wiki/OpenID

OpenID is an open standard and decentralized authentication protocol.

Promoted by the non-profit OpenID Foundation, it allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each.^[1]

Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign onto any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites according to the OpenID Foundation.^[2]

The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").^[3] An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).^[4]

The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).

The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique Uniform Resource Identifier (URI), and are managed by some "OpenID provider" that handles authentication.^[1]

Web Authorization Protocol provides an authorization model for a principal to access an application service 

http://www.potaroo.net/ietf/html/ids-wg-oauth.html

OAuth2 for Authorized Resource Access

OAuth2 use cases

OAuth2 Delegated Authorization Resource Access Flow

OAuth2 Steps

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles