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, and new specification 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).Read more
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?Read more
oidc-provider is an OpenID Connect provider for node.js, providing us with a secure authentication mechanism for our applications, and protection for our APIs. In this article, we’re going to walk through setting up oidc-provider and interacting with it using a couple of different ways.
It’s a Certified OpenID Provider Library and it’s a framework, unlike some providers which you can only mount and then modify select areas. Whilst this can be good for ensuring expected behaviour (you may be less likely to create security flaws or break functionality), it can be infuriating if you need custom logic or even grant types. The library is certified for all 5 OpenID Provider conformance profiles.
If, like me, you are a complete newbie to node.js and express.js, then the below commands are how we setup a new app...Read more
OpenID Connect presents three flows for authentication. These flows dictate how authentication is handled by the OpenID Connect Provider, including what can be sent to client application and how.
Authorization Code Flow
The authorization code flow returns an authorization code (like it says on the tin) that can then be exchanged for an identity token and/or access token. This requires client authentication using a client id and secret to retrieve the tokens from the back end and has the benefit of not exposing tokens to the user agent (i.e. a web browser). This flow allows for long lived access (through the use of refresh tokens). Clients using this flow must be able to...Read more
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.
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...Read more
Much to everyone's disappointment, OAuth 2.0 is not an authentication protocol. Instead, it is a protocol for protecting resources, where that resource is an API, and allowing a client application to access it on the owner's behalf. It is an authorization protocol. Better still, it is a delegation protocol.
Over the years a lot of people have tried to turn OAuth into an authentication protocol or bend the protocol to their will, which is why we have so many different providers, each with their own implementation depending on their view on the universe. Unsurprisingly if you look at the list of top OAuth providers it is eerily similar to the list of organisations who have been hacked in recent years. Creating your own authentication protocol is no simple task...
OpenID Connect 1.0 extends the OAuth protocol and introduces a new protected resource type: identity. This allows you to...Read more