OAuth 2.0 ​

OAuth is one of the most widely used federation protocols. It allows client applications to request permission to the user to access the user's resources stored in another application. Or, as described in the OAuth 2.0 RFC.

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Access Tokens ​

The original OAuth 2.0 describe the purpose of an access tokens but do not prescribe a certain format. Over the years, the JSON Web Token (JWT) format has become increasingly popular.

While some mistakenly believe JWT to be an standalone authentication or authorization protocol, it is not and should be used as part of a protocol that handles the secure issuing and validation of these tokens. Such as OAuth 2.0.

Idaas.nl supports the JWT token format by default. But in contrast with other provides, it supports using JWT tokens in a statefull fashion. That is, it allows revoking JWT tokens after these has been issued.

Introspect ​

While idaas.nl issues JWT access tokens, it still leverages the OAuth 2.0 introspection endpoint. This is because it allows revoking JWT access tokens.

This hybrid model has proven to be extremely valuable. It provides the best of both worlds. The easy of use and performance of JWT access tokens. But the security of opaque access tokens that depend on introspection.

Client Credentials ​

In order to support server-to-server communication, idaas.nl provides support for the client credentials grant.

PKCE ​

PKCE is the abbreviation of Proof Key for Code Exchange and pronounced as pixy.

OAuth 2.0 has been become populate especially for mobile apps. If you are familiar with app development you might know these apps can register custom urls like myapp://whatever. These urls where used as redirect_uri options in an OAuth 2.0 flow. While functionality wise this worked, a severe downside was the impossibility to ensure only the intended application received the returned authorization code.

PKCE provides an extra layer of protection. It requires exchanging an extra secret together with the authorization code in order to obtain an access token. This ensures only the requesting client can obtain an access token.

Web Message Response Mode ​

Our platform is one of the few that supports OAuth 2.0 Web Message Response Mode. This flow allows for the possibility to start a login flow via an popup or overlay on the relying parties application.

While in most OAuth flows a redirect is required to an authorization server, this flow removes the need for redirecting users and thus provides a better user experience.

A module to support this flow can be found here.

OAuth 2.0 for authentication ​

OAuth is great but core specifications do not describe how to pass over identity information. Before the introduction of OpenID Connect (OIDC), many proprietary implementations existed that introduced an identity layer on top of OAuth. Because of the introduction of OIDC there is no longer a need for these self invented protocols.