Skip to main content

Standards and Authorization Server Support

All foundational libraries within this ecosystem should support public standards as much as possible, and clearly identify which features or libraries are specific to Okta products or services.

In particular, OAuth2 and foundation libraries should work with any standards-compliant Authorization Server, without making assumptions about the target application's environment, use-case, industry, or identity service.

Furthermore, wherever possible these libraries should actively try to work on competing Okta vendors, with the goal of preventing the perception of "Vendor Lock-In", and to enable the smooth migration of customers onto Okta.

Adherence to Open Standards​

Wherever possible, the SDK APIs should adhere to, and fully support, open standards and guidelines. Naming, features, and patterns should align with public standards guidelines. When a specification differentiates between REQUIRED and OPTIONAL features or workflows, all possible supported scenarios should be supported, particularly in cases where security and verification is concerned. If however some feature is marked OPTIONAL, the SDK should not assume the remote authorization server has properly implemented it, and should be able to fall back when needed.

Support for Custom and Non-Standard Implementations​

Most of the open standards are flexible enough to allow for custom use-cases and extensions to the pubic standards. For example, The /.well-known/openid-configuration endpoint, or the response from a token request endpoing, may include additional keys or properties that aren't defined within the standard.

The SDKs should adopt features that adhere to the features defined within the specifications, while enabling graceful and easy extension to custom use-cases.

The SDKs support this in a variety of mechansims, including but not limited to:

Whenever gaps or edge-cases are discovered where these mechanisms aren't sufficient to address custom scenarios, the SDK developers may choose to:

  1. Extend these features to support a wider variety of flexibility;
  2. Create custom implementations of generic interfaces (e.g. custom authentication flows);
  3. Override built-in default implementations of OAuth2 standards behaviors (e.g. token validation).