Skip to content

list_applications fails to deserialize responses when any SAML app omits required signOn fields #536

@jychp

Description

@jychp

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
    Before submitting a bug report, we ask that you first search existing issues and pull requests to see if someone else may have experienced the same issue or may have already submitted a fix for it.

Python Version & Okta SDK Version(s)

  • Python 3.13.13
  • okta 3.4.2
  • pydantic 2.12.5

Affected Class/Method(s)

  • okta.api.application_api.ApplicationApi.list_applications
  • okta.models.saml_application_settings_sign_on.SamlApplicationSettingsSignOn

Customer Information

Organization Name: subimage
Paid Customer: yes

Code Snippet

import asyncio                                                                                                                                                                                                                                  
from okta.client import Client as OktaClient

async def main() -> None:
    client = OktaClient(
       {
            "orgUrl": "https://<yourOktaDomain>",
            "token": "<yourApiToken>",
       }                                   
    )
    apps, resp, err = await client.list_applications(limit=200)
    print(err, None if apps is None else len(apps)) 

Debug Output / Traceback

https://gist.github.com/jychp/fc84addd2c70d6709523b74d093493ca

Expected Behavior

list_applications should successfully deserialize the full paginated response on any live tenant, regardless of which SAML apps have complete sign-on configurations. Partially configured SAML apps are legitimate real-world data returned by the Okta API.

Actual Behavior

SamlApplicationSettingsSignOn declares 14 fields as strictly required (StrictStr / StrictBool), but the Okta Admin API routinely returns SAML applications that omit them. Since list_applications deserializes the entire list in one list-comprehension (api_client.py:466), a single partially-configured SAML app breaks the whole call — no apps of any sign-on type are returned to the caller.

Affected required fields declared in okta/models/saml_application_settings_sign_on.py:

  • allow_multiple_acs_endpoints (StrictBool)
  • assertion_signed (StrictBool)
  • audience (StrictStr)
  • authn_context_class_ref (StrictStr)
  • destination (StrictStr)
  • digest_algorithm (StrictStr)
  • idp_issuer (StrictStr)
  • recipient (StrictStr)
  • request_compressed (StrictBool)
  • response_signed (StrictBool)
  • signature_algorithm (StrictStr)
  • sso_acs_url (StrictStr)
  • subject_name_id_format (StrictStr)
  • subject_name_id_template (StrictStr)

This matches the same "overly restrictive validation" family as #498 and #479 (declared fixed in 3.1.0), so the pattern is known — but this specific model still trips on 3.4.2.

Steps to reproduce

  1. Against any Okta tenant that has at least one SAML app with a partial sign-on configuration (the API does not require every field above to be populated to create a SAML app), run the snippet above.
  2. Observe the 14-error ValidationError; apps is None and the sync cannot proceed.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions