Release 10.0.1

[aniket-okta]

Summary

Fixes 7 SDK issues caused by OpenAPI spec mismatches with actual Okta API responses.

Issues Fixed

Issue	Problem	Root Cause	Fix
#819	GetUserAsync returns UserGetSingleton instead of User	Spec used wrapper type	Changed response to User, removed UserGetSingleton
#816	OriginalGrant.Request always null in Token Inline Hooks	Property named request but API returns authorization	Renamed property to authorization
#815	Group.Profile.AdditionalProperties missing	additionalProperties: true removed in v10 spec	Added back to OktaUserGroupProfile and OktaActiveDirectoryGroupProfile
#814	JSON parsing errors silently swallowed	oneOf/anyOf deserialization attempted on error responses	Skip polymorphic deserialization for error responses
#812	ListGroups() returns empty for AD-synced groups	No discriminator for GroupProfile subtypes	Added objectClass discriminator with custom GroupJsonConverter
#808	ListAgentPools() fails with JSON error	lastConnection defined as date-time but API returns Unix timestamp	Changed to int64
#807	ListRolesForClientAsync returns null	Response defined as single object but API returns array	Changed to return IOktaCollectionClient<>

Reproduction & Verification

How bugs were reproduced:

1. Created POC project using NuGet SDK v10.0.0
2. Used reflection to verify return types and property names
3. Made live API calls to confirm deserialization failures
4. Observed: ListGroups() returned 0 groups, GetUserAsync returned wrong type

Verification with fixed SDK:

1. Replaced NuGet package with local project reference
2. All reflection checks passed (correct types/properties)
3. Live API calls successful:
   • ListGroups() → 5 groups returned ✅
   • ListAgentPools() → 1 pool returned ✅
   • GetUserAsync → returns User ✅

Changes

OpenAPI Spec (openapi3/management.yaml)

• Removed UserGetSingleton schema, changed getUser response to User
• Renamed OriginalGrant.request → authorization
• Added additionalProperties: true to group profile schemas
• Changed Agent.lastConnection from date-time to int64
• Changed listRolesForClient response from single object to array

Custom Code

• GroupJsonConverter.cs: Template-based converter using objectClass discriminator
• AbstractOpenAPISchema.cs: Skip oneOf/anyOf for error responses

Tests Added

• Unit tests for all fixes (deserialization/serialization)
• Integration tests: GroupApiTests, AgentPoolsApiTests, RoleAssignmentClientApiTests
• POC verification against live Okta org

Test Results

• 70 User integration tests passed
• All Group enumeration tests passed
• Agent pools API working
• Cleanup: All test resources removed from org

[aniket-okta]

Below is the main cause of all the issues and is being worked upon.

Root Cause Identified: Missing Discriminator in OpenAPI Spec

We've identified that the underlying issue is not with the missing properties, but with the OpenAPI spec's GroupProfile definition. The spec uses anyOf without a discriminator:

GroupProfile:
  anyOf:
    - $ref: '#/components/schemas/OktaUserGroupProfile'
    - $ref: '#/components/schemas/OktaActiveDirectoryGroupProfile'

Since both profile types now have identical base properties (name, description, additionalProperties: true), the SDK's deserializer cannot distinguish between them and always deserializes to OktaActiveDirectoryGroupProfile (first in the list), even for standard Okta groups.

The Real Problem:

• Standard Okta groups (created via API with OktaUserGroupProfile) are incorrectly deserialized as OktaActiveDirectoryGroupProfile
• This causes type confusion and makes it impossible to reliably identify group types in code

Proper Fix Needed:
The spec should include a discriminator property (e.g., objectClass) to distinguish between group types, as mentioned in the description:

"The objectClass of a group determines which additional properties are available."

However, the API responses don't currently include this property in the profile object, making proper deserialization impossible.

Workaround:
Until Okta fixes the spec and API to include discriminator support, the only reliable way to determine group type is via the Group.type field (not Group.profile), which correctly identifies OKTA_GROUP vs AD.

We've created an internal ticket to work with the Okta API team to add discriminator support to the Management API spec.

[aniket-okta]

Pipeline Failure Note

The CircleCI pipeline is currently failing due to Chocolatey community repository being down (returning HTTP 500 errors). This is a temporary service outage unrelated to our code changes.

Evidence:

• Chocolatey API: https://community.chocolatey.org/api/v2/ returns HTTP 500
• Status page shows maintenance/incidents for the community repository

The pipeline will resume working once Chocolatey's service is restored. No code changes are needed on our end.

[dhiwakar-okta]

LGTM 🚀