Describe the bug?
SDK is incorrectly deserializing a group into OktaActiveDirectoryGroupProfile when the group is not an AD backed Okta group.
- SDK tries to unmarshal the JSON into OktaActiveDirectoryGroupProfile first
- OktaActiveDirectoryGroupProfile has fields: description, name, dn, externalId, samAccountName, windowsDomainQualifiedName, plus AdditionalProperties
- Since your group has name and description in the JSON, and AdditionalProperties catches everything else (your custom fields like owner, teams, etc.), it doesn't marshal back to {}
- So the SDK thinks it matched OktaActiveDirectoryGroupProfile and returns early without ever trying OktaUserGroupProfile
It's a bug in the SDK's anyOf deserialization — since both types have overlapping fields and both have AdditionalProperties as a catch-all, OktaActiveDirectoryGroupProfile always wins because it's
tried first. Your group IS a user group, but the SDK can't distinguish them this way.
The real discriminator should be the objectClass field (okta:user_group vs okta:windows_security_principal), but the SDK doesn't use it during deserialization.
What is expected to happen?
The real discriminator should be the objectClass field (okta:user_group vs okta:windows_security_principal), but the SDK doesn't use it during deserialization.
If it is not an AD backed group then the group profile should be deserialized and returned using OktaUserGroupProfile instead.
What is the actual behavior?
Incorrectly deserializing to OktaActiveDirectoryGroupProfile
Reproduction Steps?
Run ListGroups with a search string returning non-AD backed groups
Iterate through the result set
have a Getter Helper function like this:
func GroupGetName(g *oktasdk.Group) string {
if g != nil {
profile := g.GetProfile()
if profile.OktaUserGroupProfile != nil {
return profile.OktaUserGroupProfile.GetName()
}
}
return ""
}
returns an empty result unexpectedly because the deserialization is going to the wrong type
Additional Information?
This code previously worked in v4:
github.com/okta/okta-sdk-golang/v4 v4.1.2
Golang Version
go version go1.25.4 darwin/arm64
SDK Version
from go.mod:
github.com/okta/okta-sdk-golang/v6 v6.1.6
OS version
Darwin 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:15 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6041 arm64 arm Darwin
Describe the bug?
SDK is incorrectly deserializing a group into OktaActiveDirectoryGroupProfile when the group is not an AD backed Okta group.
It's a bug in the SDK's anyOf deserialization — since both types have overlapping fields and both have AdditionalProperties as a catch-all, OktaActiveDirectoryGroupProfile always wins because it's
tried first. Your group IS a user group, but the SDK can't distinguish them this way.
The real discriminator should be the objectClass field (okta:user_group vs okta:windows_security_principal), but the SDK doesn't use it during deserialization.
What is expected to happen?
The real discriminator should be the objectClass field (okta:user_group vs okta:windows_security_principal), but the SDK doesn't use it during deserialization.
If it is not an AD backed group then the group profile should be deserialized and returned using OktaUserGroupProfile instead.
What is the actual behavior?
Incorrectly deserializing to OktaActiveDirectoryGroupProfile
Reproduction Steps?
Run ListGroups with a search string returning non-AD backed groups
Iterate through the result set
have a Getter Helper function like this:
func GroupGetName(g *oktasdk.Group) string {
}
returns an empty result unexpectedly because the deserialization is going to the wrong type
Additional Information?
This code previously worked in v4:
github.com/okta/okta-sdk-golang/v4 v4.1.2
Golang Version
go version go1.25.4 darwin/arm64
SDK Version
from go.mod:
github.com/okta/okta-sdk-golang/v6 v6.1.6
OS version
Darwin 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:15 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6041 arm64 arm Darwin