Okta Sdk Java

Java SDK for Okta Resource Management
Alternatives To Okta Sdk Java
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Wechat4,140269 hours ago58August 08, 202295apache-2.0Go
WeChat SDK for Go (微信SDK:简单、易用)
Octokit.rb3,76136,2266655 days ago129September 14, 202260mitRuby
Ruby toolkit for the GitHub API
Fosite2,0615064a month ago278April 17, 202231apache-2.0Go
Extensible security first OAuth 2.0 and OpenID Connect SDK for Go.
Node Wit1,945547403 months ago27July 15, 202236otherJavaScript
Node.js SDK for Wit.ai
Line Bot Sdk Python1,665523113 days ago31June 15, 202211apache-2.0Python
LINE Messaging API SDK for Python
Facebook Python Business Sdk1,117218a day ago72June 30, 202223otherPython
An SDK built to facilitate application development for Facebook Ads API.
Auth0 Spa Js7921441102 days ago68June 14, 20221mitTypeScript
Auth0 authentication for Single Page Applications (SPA) with PKCE
Mapbox Navigation Ios787
156 days ago93July 08, 2022185otherSwift
Turn-by-turn navigation logic and UI in Swift on iOS
Facebook Php Business Sdk7485710a day ago113July 12, 202210otherPHP
An SDK built to facilitate application development for Facebook Ads API.
Python Weixin741
102 years ago31June 10, 20197otherPython
微信(weixin|wechat) Python SDK 支持开放平台和公众平台 支持微信小程序云开发
Alternatives To Okta Sdk Java
Select To Compare

Alternative Project Comparisons

Maven Central License Support API Reference

Okta Java Management SDK

This repository contains the Okta management SDK for Java. This SDK can be used in your server-side code to interact with the Okta management API and:

We also publish these libraries for Java:

You can learn more on the Okta + Java page in our documentation.

Release status

This library uses semantic versioning and follows Okta's library version policy.

✔️ The latest stable major version series is: 10.x.x

Version Status
0.0.x, 1.x, 2.x.x, 3.x.x, 4.x.x, 5.x.x, 6.x.x, 7.x.x, 8.x.x ⚠️ Retired
9.x.x-beta, 10.x.x-beta ⚠️ Beta release (discontinued)
10.x.x ✔️ Stable (migration guide)

The latest release can always be found on the releases page.

Need help?

If you run into problems using the SDK, you can:

Getting started


  • JDK 8 or later

To use this SDK, you will need to include the following dependencies:

For Apache Maven:


For Gradle:

compile "com.okta.sdk:okta-sdk-api:${okta.sdk.version}"
runtime "com.okta.sdk:okta-sdk-impl:${okta.sdk.version}"

where ${okta.sdk.version} is the latest published version in Maven Central.

SNAPSHOT Dependencies

Snapshots are deployed off of the 'master' branch to OSSRH and can be consumed using the following repository configured for Apache Maven or Gradle:


You will also need:

Construct a client instance by passing it your Okta domain name and API token:

ApiClient client = Clients.builder()
    .setOrgUrl("https://{yourOktaDomain}")  // e.g. https://dev-123456.okta.com
    .setClientCredentials(new TokenClientCredentials("{apiToken}"))

Hard-coding the Okta domain and API token works for quick tests, but for real projects you should use a more secure way of storing these values (such as environment variables). This library supports a few different configuration sources, covered in the configuration reference section.

OAuth 2.0

Okta allows you to interact with Okta APIs using scoped OAuth 2.0 access tokens. Each access token enables the bearer to perform specific actions on specific Okta endpoints, with that ability controlled by which scopes the access token contains.

This SDK supports this feature only for service-to-service applications. Check out our guides to learn more about how to register a new service application using a private and public key pair.

Check out our guide to learn how to generate a JWK and convert the same to PEM format which would be used as PrivateKey in Client creation.

When using this approach, you will not need an API Token because the SDK will request an access token for you. In order to use OAuth 2.0, construct a client instance by passing the following parameters:

ApiClient client = Clients.builder()
    .setOrgUrl("https://{yourOktaDomain}")  // e.g. https://dev-123456.okta.com
    .setKid("{kid}") // optional
    .setScopes(new HashSet<>(Arrays.asList("okta.users.manage", "okta.apps.manage", "okta.groups.manage")))
    // (or) .setPrivateKey("full PEM payload")
    // (or) .setPrivateKey(Paths.get("/path/to/yourPrivateKey.pem"))
    // (or) .setPrivateKey(inputStream)
    // (or) .setPrivateKey(privateKey)
    // (or) .setOAuth2AccessToken("access token string") // if set, private key (if supplied) will be ignored

Usage guide

These examples will help you understand how to use this library. You can also browse the full API reference documentation.

Once you initialize a ApiClient instance, you can pass this instance to the constructor of any API area clients (such as UserApi, GroupApi, ApplicationApi etc.). You can start using these clients to call management APIs relevant to the chosen API area.

Authenticate a User

This library should be used with the Okta management API. For authentication, we recommend using an OAuth 2.0 or OpenID Connect library such as Spring Security OAuth or Okta's Spring Boot integration. For Okta Authentication API you can use Authentication SDK.

Get a User

UserApi userApi = new UserApi(client);
User user = userApi.getUser("userId");

List all Users

UserApi userApi = new UserApi(client);
List<User> users = userApi.listUsers(null, null, 5, null, null, null, null);

// stream
    .forEach(user -> {
      // do something

For more examples of handling collections see the paging section below.

Filter or search for Users

UserApi userApi = new UserApi(client);

// search by email
List<User> users = userApi.listUsers(null, null, 5, null, "profile.email eq \"[email protected]\"", null, null);

// filter parameter
users = userApi.listUsers(null, null, null, "status eq \"ACTIVE\"",null, null, null);

Create a User

UserApi userApi = new UserApi(client);
User user = UserBuilder.instance()
    .setEmail("[email protected]")

Create a User with Group(s)

UserApi userApi = new UserApi(client);
User user = UserBuilder.instance()
    .setEmail("[email protected]")
    .setGroups(Arrays.asList("groupId-1", "groupId-2"))

Update a User

UserApi userApi = new UserApi(client);
UpdateUserRequest updateUserRequest = new UpdateUserRequest();
UserProfile userProfile = new UserProfile();
userApi.updateUser(user.getId(), updateUserRequest, true);

Remove a User

UserApi userApi = new UserApi(client);

// deactivate first
userApi.deactivateUser(user.getId(), false);

// then delete
userApi.deleteUser(user.getId(), false);

List a User's Groups

GroupApi groupApi = new GroupApi(client);
List<Group> groups = groupApi.listGroups(null, null, null, 10, null, null, null, null);

Create a Group

GroupApi groupApi = new GroupApi(client);
Group group = GroupBuilder.instance()
    .setDescription("Example Group")

Add a User to a Group

// create user
UserApi userApi = new UserApi(client);
User user = UserBuilder.instance()
    .setEmail("[email protected]")

// create group
GroupApi groupApi = new GroupApi(client);
Group group = GroupBuilder.instance()
    .setDescription("Example Group")

// assign user to group
groupApi.assignUserToGroup(group.getId(), user.getId());

List a User's enrolled Factors

UserFactorApi userFactorApi = new UserFactorApi(client);
List<UserFactor> userFactors = userFactorApi.listFactors("userId");

Enroll a User in a new Factor

UserFactorApi userFactorApi = new UserFactorApi(client);
SmsUserFactorProfile smsUserFactorProfile = new SmsUserFactorProfile();
smsUserFactorProfile.setPhoneNumber("555 867 5309");
SmsUserFactor smsUserFactor = new SmsUserFactor();
UserFactor userFactor = userFactorApi.enrollFactor("userId", smsUserFactor, true, "templateId", 30, true);

Activate a Factor

UserFactorApi userFactorApi = new UserFactorApi(client);
UserFactor userFactor = userFactorApi.getFactor("userId", "factorId");
ActivateFactorRequest activateFactorRequest = new ActivateFactorRequest();
UserFactor activatedUserFactor = userFactorApi.activateFactor("userId", "factorId", activateFactorRequest);

Verify a Factor

UserFactorApi userFactorApi = new UserFactorApi(client);
UserFactor userFactor = userFactorApi.getFactor("userId", "factorId");
VerifyFactorRequest verifyFactorRequest = new VerifyFactorRequest();
VerifyUserFactorResponse verifyUserFactorResponse =
    userFactorApi.verifyFactor("userId", "factorId", "templateId", 10, "xForwardedFor", "userAgent", "acceptLanguage", verifyFactorRequest);

List all Applications

List<Application> applications = ApplicationApiHelper.listApplications(client, null, null, null, null, null, true);

Get an Application

ApplicationApi applicationApi = new ApplicationApi(client);

// get generic application type
Application genericApp = applicationApi.getApplication("app-id", null);

// get sub-class application type
BookmarkApplication bookmarkApp = ApplicationApiHelper.getApplication(client, "bookmark-app-id", null);

Create a SWA Application

ApplicationApi applicationApi = new ApplicationApi(client);
SwaApplicationSettingsApplication swaApplicationSettingsApplication = new SwaApplicationSettingsApplication();
SwaApplicationSettings swaApplicationSettings = new SwaApplicationSettings();
BrowserPluginApplication browserPluginApplication = new BrowserPluginApplication();
browserPluginApplication.label("Sample Plugin App");

// create
BrowserPluginApplication createdApp =
    applicationApi.createApplication(BrowserPluginApplication.class, browserPluginApplication, true, null);

List Policies

List<Policy> policies = PolicyApiHelper.listPolicies(client, PolicyType.PASSWORD.name(), LifecycleStatus.ACTIVE.name(), null);

Get a Policy

PolicyApi policyApi = new PolicyApi(client);

// get generic policy type
Policy genericPolicy = PolicyApiHelper.getPolicy(client, "policy-id", null);

// get sub-class policy type
MultifactorEnrollmentPolicy mfaPolicy = PolicyApiHelper.getPolicy(client, "mfa-policy-id", null);

List System Logs

SystemLogApi systemLogApi = new SystemLogApi(client);

// use a filter (start date, end date, filter, or query, sort order) all options are nullable
List<LogEvent> logEvents = systemLogApi.listLogEvents(null, null, null, "interestingURI.com", 100, "ASCENDING", null);

Call other API endpoints

Not every API endpoint is represented by a method in this library. You can call any Okta management API endpoint using this generic syntax:

ApiClient apiClient = buildApiClient("orgBaseUrl", "apiKey");

// Create a BookmarkApplication
BookmarkApplication bookmarkApplication = new BookmarkApplication();
bookmarkApplication.setLabel("Sample Bookmark App");
BookmarkApplicationSettings bookmarkApplicationSettings = new BookmarkApplicationSettings();
BookmarkApplicationSettingsApplication bookmarkApplicationSettingsApplication =
    new BookmarkApplicationSettingsApplication();
ResponseEntity<BookmarkApplication> responseEntity = apiClient.invokeAPI("/api/v1/apps",
    new HttpHeaders(),
    new LinkedMultiValueMap<>(),
    new String[]{"API Token"},
    new ParameterizedTypeReference<BookmarkApplication>() {});
BookmarkApplication createdApp = responseEntity.getBody();

Thread Safety

Every instance of the SDK Client is thread-safe. You should use the same instance throughout the entire lifecycle of your application. Each instance has its own Connection pool and Caching resources that are automatically released when the instance is garbage collected.


UserApi userApi = new UserApi(client);
int limit = 2;
PagedList<User> pagedUserList = userApi.listUsersWithPaginationInfo(null, null, limit, null, null, null, null);

// loop through all of them
for (User tmpUser : pagedUserList.getItems()) {
    log.info("User: {}", tmpUser.getProfile().getEmail());

// or stream
pagedUserList.getItems().forEach(tmpUser -> log.info("User: {}", tmpUser.getProfile().getEmail()));

Inject the Okta Java SDK in Spring

To integrate the Okta Java SDK into your Spring Boot application you just need to add a dependency:


Then define the following properties:

Key Description
okta.client.orgUrl Your Okta Url: https://{yourOktaDomain}, i.e. https://dev-123456.okta.com
okta.client.token An Okta API token, see creating an API token for more info.

NOTE: The configuration techniques described in the configuration reference section will work as well.

All that is left is to inject the client (com.okta.sdk.client.Client)! Take a look at this post for more info on the best way to inject your beans.

For more information check out the Okta Spring Boot Starter project!

Configuration reference

This library looks for configuration in the following sources:

  1. An okta.yaml at the root of the applications classpath
  2. An okta.yaml file in a .okta folder in the current user's home directory (~/.okta/okta.yaml or %userprofile%\.okta\okta.yaml)
  3. Environment variables
  4. Java System Properties
  5. Configuration explicitly set programmatically (see the example in Getting started)

Higher numbers win. In other words, configuration passed via the constructor will override configuration found in environment variables, which will override configuration in okta.yaml (if any), and so on.

YAML configuration

The full YAML configuration looks like:

    connectionTimeout: 30 # seconds
    orgUrl: "https://{yourOktaDomain}" # i.e. https://dev-123456.okta.com
      port: null
      host: null
      username: null
      password: null
    token: yourApiToken
    requestTimeout: 0 # seconds
      maxRetries: 4

Environment variables

Each one of the configuration values above can be turned into an environment variable name with the _ (underscore) character:

  • and so on

System properties

Each one of the configuration values written in 'dot' notation to be used as a Java system property:

  • okta.client.connectionTimeout
  • okta.client.token
  • and so on

Connection Retry

By default, this SDK will retry requests that return with response code 503, 504, 429(caused by rate limiting), or socket/connection exceptions.

Default configuration tells SDK to retry requests up to 4 times without time limitation:

okta.client.requestTimeout = 0 //Sets the maximum number of seconds to wait when retrying before giving up.
okta.client.rateLimit.maxRetries = 4 //Sets the maximum number of attempts to retrying before giving up.

For interactive clients (i.e. web pages) it is optimal to set requestTimeout to be 10 sec (or less, based on your needs), and the maxRetries attempts to be 0. This means the requests will retry as many times as possible within 10 seconds:

okta.client.requestTimeout = 10
okta.client.rateLimit.maxRetries = 0


import com.okta.sdk.client.Client;
import com.okta.sdk.client.Clients;

Client client = Clients.builder()

For batch/non-interactive processes optimal values are opposite. It is optimal to set requestTimeout to be 0, and the maxRetries attempts to be 5. The SDK will retry requests up to 5 times before failing:

okta.client.requestTimeout = 0
okta.client.rateLimit.maxRetries = 5

If you need to limit execution time and retry attempts, you can set both requestTimeout and the maxRetries. For example, the following example would retry up to 15 times within 30 seconds:

okta.client.requestTimeout = 30
okta.client.rateLimit.maxRetries = 15

To disable the retry functionality you need to set both variables to zero:

okta.client.requestTimeout = 0
okta.client.rateLimit.maxRetries = 0


By default, a simple production-grade in-memory CacheManager will be enabled when the Client instance is created. This CacheManager implementation has the following characteristics:

  • It assumes a default time-to-live and time-to-idle of 1 hour for all cache entries.
  • It auto-sizes itself based on your application's memory usage. It will not cause OutOfMemoryExceptions.

The default cache manager is not suitable for an application deployed across multiple JVMs.

This is because the default implementation is 100% in-memory (in-process) in the current JVM. If more than one JVM is deployed with the same application codebase - for example, a web application deployed on multiple identical hosts for scaling or high availability - each JVM would have it's own in-memory cache.

As a result, if your application that uses an Okta Client instance is deployed across multiple JVMs, you SHOULD ensure that the Client is configured with a CacheManager implementation that uses coherent and clustered/distributed memory.

See the ClientBuilder Javadoc for more details on caching.

Caching for applications deployed on a single JVM

If your application is deployed on a single JVM and you still want to use the default CacheManager implementation, but the default cache configuration does not meet your needs, you can specify a different configuration. For example:

    .withDefaultTimeToLive(300, TimeUnit.SECONDS) // default
    .withDefaultTimeToIdle(300, TimeUnit.SECONDS) //general default
    .withCache(forResource(User.class) //User-specific cache settings
        .withTimeToLive(1, TimeUnit.HOURS)
        .withTimeToIdle(30, TimeUnit.MINUTES))
    .withCache(forResource(Group.class) //Group-specific cache settings
        .withTimeToLive(1, TimeUnit.HOURS))
    //... etc ...

Disable Caching

While production applications will usually enable a working CacheManager as described above, you might wish to disable caching entirely. You can do this by configuring a disabled CacheManager instance. For example:

ApiClient client = Clients.builder()

Building the SDK

In most cases, you won't need to build the SDK from source. If you want to build it yourself, take a look at the build instructions wiki (though just cloning the repo and running mvn install should get you going).


We are happy to accept contributions and PRs! Please see the contribution guide to understand how to structure a contribution.

Popular Sdk Projects
Popular Token Projects
Popular Libraries Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.