OpenID Connect (OIDC) and OAuth2 Authentication Libraries
It’s 2018. At this point, application developers should not be writing code that directly implements HTTPS calls to OAuth2 or OpenID Connect endpoints, token caching, token refreshes, token validation, or other such activities. An authentication library should be used that implements these functions. In the early days of OAuth 1.x and even OAuth2, it was common to pitch these protocols as so simple they can be implemented directly with no need for a library. As these protocols have become mainstream and embraced by organizations, large and small, with complex Identity requirements that rely upon proprietary features or extension specifications, the need for the authentication library has grown.
Almost every major Identity Provider (IdP) vendor that supports OpenID Connect (or OAuth2) has a published list of recommendations for client authentication libraries spanning different platforms and application types. The vendors may have created their own or recommend a third-party (probably Open Source) library. Those libraries will have assumptions built in about which OAuth2 Authorization Grants and OIDC Authentication Flows are supported. This will likely impose limitations on which spec features can be utilized.
I use the phrase “authentication library”. Some vendors call it an SDK, authentication SDK, client SDK, or some other combination of these words.
Almost all IdP vendors have value-add features (typically proprietary) that have been implemented to differentiate their products and provide a more complete offering. To utilize these features, it is likely that the authentication library will have to be able to add custom parameters to the OAuth2 (or OIDC) calls it makes. If a third-party library or OSS library is used that is a general-purpose OAuth2 (or OIDC) library, there probably isn’t support for adding these custom parameters. Typically, an IdP would offer their own authentication library that can take advantage of these proprietary features.
Another differentiating feature of various authentication libraries is what IdP interface is used to authenticate users, obtain tokens, and perform other functions. A spec-defined interface is preferable to using proprietary IdP interfaces, but many libraries use the proprietary approach. Ideally, a library would be used that relies upon the spec-defined interfaces. This makes it easier to migrate to another solution if needed. Though, those value-add features mentioned earlier may require proprietary interfaces.
Here are links to some of the library recommendations for IdPs that I commonly use.
- Red Hat SSO
- KeyCloak
- Azure Active Directory
- ADFS (this link mentions that the Microsoft ADAL libraries can be used with ADFS)
- PingONE
- Ping Federation
- AWS Cognito (tends to steer developers towards SDKs that use proprietary interfaces. Check out the AWS Cognito Auth SDK for Javascript as an example of a library that uses the OIDC interface).
- Okta
- Auth0
The OpenID Foundation has an authentication library called AppAuth that supports Javascript/node.js, iOS, Android, and other platforms. The benefit (and limitation) of this library is adherence to the spec. This means it can be used with any OIDC compliant IdP (OpenID Provider to be accurate), but it also complicates using proprietary IdP features.
Most IdPs will publish the details of their OAuth2 and OIDC implementation endpoints so that they can be used without libraries. This is helpful if you are trying to make a third-party library integrate with an IdP and custom parameters need to be passed to the IdP. In line with the general theme of this post, I generally don’t recommend coding the direct interaction with these endpoints.
Image: we grow into the light / Rudolf Getel
