OpenID Connect is a protocol for authentication built on top of OAuth 2.0. In this case, the thing you are delegating is your logged-in identity, which usually means a verified email address.

This is how you make a login with AmaGooFaceSoft button.

The lead specification writer for OAuth 2.0 took his ball home, claiming that, because of the involvement of enterprise developers in the working group, the specification had become complex and vague.

It's therefore very unlikely that different implementations will be interoperable. Furthermore, it's quite easy to create an insecure implementation.

The objections here seem valid.

The user-operated client program exchanges tokens (usually JSON Web Tokens) with various parties.

Id token (OpenID Connect)

claims that the bearer has authenticated as a person, with some specific details about who they are. The consumer of this token is an authorisation server. You can also use it to display personallized greetings to the user.

Access token (OAuth 2.0)

claims that the bearer is authorized to access some functions of an API. This token may have some user information baked in, but it shouldn't leak personal details. The consumer of this token is a specific resource provider.

Refresh token (OAuth 2.0)

a way to get a new access token.

These are all signed, and you need to verify the signature. You should also check the expiration.

Lastly, there is be a state parameter which you set in your request, and should come back in the response. You can use this to prove that this token was sent to you in response to the known request that you made.

This is when the application is also the resource owner. We use client credentials grant.

We use our client it to ask for an access token, and then send it in API requests.

The user usually has to authorize specific client ids.

authorisation code grant

1. Browser visits resource owner server: /authorize?redirect_uri=my-web-app.
2. User agrees to requested permissions.
3. Resource owner server page redirects browser to your web app, including an Authorisation code.
4. Client-side web app code sends Authorisation code to backend server.
5. Backend visits authorisation server /oauth/token URL, passing Authorisation code. Gets back access token, and maybe other tokens too.
6. Backend calls APIs and sends result to browser.

In practice, the resource owner server and the authorisation server are likely the same?

There's an implementation guide for NodeJS here: https://auth0.com/docs/quickstart/webapp/nodejs.

This is less good. You can use implicit grant, but the OAuth 2.0 website says not to.

1. Browser visits authentication server: /authorize?redirect_url=my-web-app.
2. User agrees permissions.
3. Authentication server redirects browser to your web app. Access token is included in the hash fragment.

When authorizing, include prompt=none — as in — /authorize?redirect_url=my-web-app&prompt=none.

Auth0 is a company which provides OAuth 2.0 and OpenID Connect support, including delegation to other OpenID Connect providers.

Their main selling points are lots of customization.

They offer lock, which is a lock screen widget for the web.

Another product they provide is guardian, which is multi-factor authentication.

This provides both authentication and authorisation.

It's an implementation of SAML 2.0, but it also provides OAuth 2.0.