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
- 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.
- Observe the 14-error ValidationError; apps is None and the sync cannot proceed.
References
Community Note
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)
Affected Class/Method(s)
Customer Information
Organization Name: subimage
Paid Customer: yes
Code Snippet
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:
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
References
assign_user_to_applicationdocs markAppUser.profileas optional, but function fails without it and requires dict input #479