Sign in with Apple was recently released as part of Apple’s WWDC 2019 conference. They’ve essentially weighed into the identity provider space with the username and password being handled by Apple ID and 2FA handled by your registered Apple devices.
Sign In with Apple gives us a new alternative to other social login providers such as Google and Facebook. However, unlike those services, it seems to be more aimed at 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 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.
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.
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.