Skip to main content

Foundation Guidelines

The Okta Client SDK consists of a set of libraries, each of which build on each other, to allow developers to easily integrate secure authentication and HTTP request authorization into their apps.

The SDK Architecture is also designed to be implemented in multiple languages (e.g. Swift, Kotlin/Java, TypeScript/JavaScript, .NET, etc), with support for a variety of environments (Mobile applications, CLI utilities, SPA or server-side web applications, backend environments, etc).

In orer to avoid confusion and maintenance problems across these various languages and environments, it's critical that these implementations align with one-another, meeting common design guidelines to ensure:

  • Architectural Parity – The structure and relationships between library components, and the classes/interfaces within them, match across languages and environments.
  • Naming consistency – Classes, interfaces, properties, and functions are named consistently across implementations (with affordances made for language-specific guidance).
  • Feature Parity – Features, capabilities, developer- and user-stories supported should be consistently adopted across languages and environments.

Modular library ecosystem​

These SDK components are modularized into different libraries/frameworks that encapsulate their specific capabilities, and enable a) other libraries to be built upon them, and b) provide targeted extension points for customers to alter behavior in a more consistent and reliable manner.

The library ecosystem is largely divided into four separate sections:

  1. Foundational / common capabilities shared by all upstream libraries.
  2. Low-level authentication libraries that implement specific styles of authentication flows.
  3. UI libraries to simplify integration into different application environments.
  4. Feature libraries which build upon the foundation to use user credentials after sign-in, agnostic of how the user was authenticated.

Each library layer is directly accessible to the app developer, which allows them to interact directly with the user-facing SDK they choose to use, or to work with lower layers (either partially or exclusively) to customize their login experience as they see fit.

For example, the following is an illustration of some of these libraries, and how their components relate to one-another: