OpenID Connect

OpenID Connect builds upon OAuth 2 with a new token type: the ID token (identity token). This identity token allows client applications to start understanding users and authentication, which isn’t possible with OAuth alone. However, with a new token type comes something new to learn, a new set of misunderstandings, and new ways for things to go wrong.

In this article, you will learn what identity tokens are, where to use them, and how to validate them, dispelling some common myths along the way. You’ll also see some advanced scenarios where identity tokens can help you with elevation scenarios such as step-up authentication.

“Sign In With Apple” (SIWA) is Apple’s response to social authentication methods, similar to google. Released as part of Apple’s WWDC 2019 conference, Apple has weighed into the identity provider space by using Apple ID for username and password authentication and MFA using the user’s registered Apple devices.

Sign in with Apple gives you a new alternative to other social login providers such as Google and Facebook. However, unlike those services, it has a greater focus on identity and authentication rather than access to services such as Google calendar.

Proof Key for Code Exchange (PKCE) was initially designed for native/mobile client applications when using OAuth; however, as a happy accident, it’s also handy for all other kinds of applications. Because of this, new specifications and BCP documents are starting to encourage the use of PKCE across the board.

PKCE allows us to ensure that the client application swapping an authorization code for tokens, is the same application that initially requested the authorization code. It protects us from bad actors from stealing authorization codes and using them.

In this article, we’re going to see how we can add PKCE support to an existing ASP.NET Core OpenID Connect client application (with some IdentityServer4 config thrown in for good measure).

Or, it’s not IdentityServer, it’s you.

A common issue with when integrating with an OpenID Provider, such as IdentityServer4, is getting caught in an infinite redirect loop. Typically, this redirect loop will eventually crash your browser tab, or the browser itself.

In Chrome, you’d get the ERR_TOO_MANY_REDIRECTS error message. Or, if you’re issuing cookies to track nonce and states values with each redirect and not cleaning up after yourself (I’m looking at you OWIN/Katana), then you’ll probably get an a 400 Bad Request, with a message of something like “The size of the request headers is too long”.

When using the implicit authentication flow refresh tokens cannot be requested or used, since the client application cannot be explicitly or securely authenticated and therefore cannot be trusted with such a sensitive token. This also applies to any flow on a public client incapable of keeping a secret or making secure back channel requests. If a refresh token intended for a such a client was stolen, the thief could use it to request access tokens for that user, without their knowledge or consent.

When using a client application running in the browser, which the OpenID Connect implicit flow was designed for, we expect the user to be present at the client application. They might be currently in a different tab or even on a different application than the browser, but the session is still active. This means that if their access token expires, they should still be around to authorize another to be issued. We’re not expecting the client application to be performing any sort of background tasks or long-running processing.

But what if, for instance, the user was filling out a form in the application and their access token expired?

oidc-provider is an OpenID Connect library for node.js, allowing you to create your own OAuth authorization server and OpenID provider.

In this article, you’ll see how fast it can be to set up your own authorization server with oidc-provider and how to use it with some basic OAuth and OpenID Connect use cases.

OpenID Connect defines three flows, two of which build upon flows defined in OAuth 2.0. These flows dictate what response types an authorization request can request and how tokens are returned to the client application.

This article describes each flow, when to use it, and how to secure it.

OpenID Connect specifies three core endpoints that must be provided to meet its core specification and three other optional endpoints that aid with automation, discovery and session management.

Core

Authorization Endpoint

Carried across from OAuth, this endpoint authorises access a protected resource. This resource could be the resource owners identity or an API.

This endpoint will require the resource owner to first authenticate (log in) and then give their consent to for you to access their protected resources. Assume that this endpoint will always require interaction with the resource owner...

OpenID Connect (OIDC) provides a simple identity layer on top of the OAuth 2.0 protocol, enabling Single Sign-On (SSO) and API access in one round trip. It brings the missing user authentication story and identity layer to OAuth.

In this article, you’ll see how OpenID Connect differs from OAuth, and key OpenID Connect features such as identity tokens and the user info endpoint.