Application.features enum missing AUTO_CONFIRM_IMPORTS, and BrowserPluginApplication rejects OIN catalog SWA apps (separate from #546)

[jasonhernandez]

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.

Python Version & Okta SDK Version(s)

• Python 3.13.2
• okta-sdk-python 3.4.2, 3.4.3, 3.4.4 (all tested)
• pydantic 2.13.4

Affected Class/Method(s)

• okta.models.application.Application.features (features_validate_enum)
• okta.models.browser_plugin_application.BrowserPluginApplication.name
• okta.models.swa_application_settings_application.SwaApplicationSettingsApplication
• okta.api.application_api.ApplicationApi.list_applications

Customer Information

Organization Name: Materialize, Inc.
Paid Customer: yes

Scope — and what this issue is not about

The missing StrictBool fields on SamlApplicationSettingsSignOn are already tracked in #546 and are deliberately excluded here. This issue was originally filed covering that as well; it has been edited down so #546 remains the single thread for it.

What remains below are two separate deserialization defects, in different models with different mechanisms, that are not reported elsewhere. They matter because they are enough on their own to break list_applications for an entire tenant — so fixing #546 will not be sufficient.

Summary

Generated Application models enforce required and enum constraints that the Okta Admin API does not satisfy for real applications. Two instances, both confirmed on 3.4.4:

#	Defect	Model
1	features enum is missing AUTO_CONFIRM_IMPORTS	Application.features
2	name enum excludes OIN catalog SWA apps; settings.app.* required	BrowserPluginApplication

Measured against one production tenant (50 apps, filter=signOnMode eq "SAML_2_0"), feeding each app individually into ApplicationJsonConverter.from_dict:

	count
Apps returned by the API	50
Fail to deserialize, total	39
— attributable to #546 (missing booleans)	33
— attributable to defect 1 below	5
— attributable to defect 2 below	1
Deserialize cleanly	11

Because api_client.py::__deserialize validates an entire page in one list comprehension, any single failure makes list_applications return None for all 50 apps. So even with #546 fully fixed, the 6 apps failing for the two defects below still blank the entire tenant. There is no per-item tolerance, so a caller cannot skip the offending apps.

Code Snippet

Both defects reproduce with no credentials and no network access. Note that the SAML payload below has a fully populated signOn block, which isolates it from #546:

from importlib.metadata import version
from okta.models.application_json_converter import ApplicationJsonConverter
from pydantic import ValidationError

print("okta:", version("okta"), "\n")

# 1. Custom SAML app with SCIM provisioning. The signOn block is fully populated,
#    so this is isolated from the missing-boolean problem tracked in #546.
custom_saml_features = {
    "id": "0oaFeatures", "name": "myorg_app_1", "label": "Custom SAML app",
    "status": "ACTIVE", "signOnMode": "SAML_2_0",
    "features": ["PUSH_NEW_USERS", "AUTO_CONFIRM_IMPORTS", "SCIM_PROVISIONING"],
    "settings": {"signOn": {
        "allowMultipleAcsEndpoints": False, "assertionSigned": True,
        "honorForceAuthn": True, "requestCompressed": False, "responseSigned": True,
        "audience": "https://ex", "destination": "https://ex", "idpIssuer": "https://ex",
        "recipient": "https://ex", "ssoAcsUrl": "https://ex",
        "digestAlgorithm": "SHA256", "signatureAlgorithm": "RSA_SHA256",
        "authnContextClassRef":
            "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
        "subjectNameIdFormat":
            "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
        "subjectNameIdTemplate": "${user.userName}",
    }},
}

# 2. OIN catalog SWA app, BROWSER_PLUGIN sign-on mode.
oin_swa = {
    "id": "0oaOinSwa", "name": "docusign", "label": "DocuSign",
    "status": "ACTIVE", "signOnMode": "BROWSER_PLUGIN", "settings": {},
}

for title, payload in (
    ("1. features contains AUTO_CONFIRM_IMPORTS", custom_saml_features),
    ("2. OIN catalog SWA app (name=docusign)", oin_swa),
):
    print(title)
    try:
        app = ApplicationJsonConverter.from_dict(payload)
        print(f"   OK -> {type(app).__name__}\n")
    except ValidationError as e:
        for x in e.errors():
            loc = ".".join(str(p) for p in x["loc"])
            print(f"   {x['type']:<14} {loc}")
            if x["type"] == "value_error":
                print(f"                  {x['msg'][:150]}...")
        print()

Debug Output / Traceback

okta: 3.4.4

1. features contains AUTO_CONFIRM_IMPORTS
   value_error    features
                  Value error, each list item must be one of ('GROUP_PUSH', 'IMPORT_NEW_USERS', 'IMPORT_PROFILE_UPDATES', 'IMPORT_USER_SCHEMA', 'PROFILE_MASTERING', 'PU...

2. OIN catalog SWA app (name=docusign)
   value_error    name
                  Value error, must be one of enum values ('template_swa', 'template_swa3field')...

Actual Behavior

Defect 1 — Application.features enum is missing AUTO_CONFIRM_IMPORTS

Application.features is typed Optional[List[StrictStr]], but carries a features_validate_enum validator restricting each item to a hardcoded 42-value set. The Okta API returns AUTO_CONFIRM_IMPORTS for custom SAML apps with SCIM provisioning enabled, and that value is not in the set, so the validator raises value_error and the app fails to deserialize.

In the measured tenant this hit 5 of 50 apps — all custom SAML apps whose signOn block is fully populated, so they are unaffected by #546 and would still fail after it is fixed.

This is a distinct mechanism from #546: an incomplete generated enum rather than an over-strict required declaration.

Defect 2 — BrowserPluginApplication.name enum excludes every OIN catalog SWA app

BrowserPluginApplication.name is constrained to ('template_swa', 'template_swa3field'), so an Okta Integration Network catalog SWA app cannot deserialize — its name is the catalog template id (docusign in the measured tenant), not one of the two generic SWA templates. The same payload additionally produces missing errors for settings.app.buttonField, settings.app.passwordField, settings.app.url, and settings.app.usernameField, which OIN SWA apps do not return.

This one shows the problem is not confined to SAML models. The measured run filtered to signOnMode eq "SAML_2_0", so an unfiltered list_applications over the same tenant would likely surface additional sign-on modes failing the same way.

Expected Behavior

list_applications should deserialize any application the Okta Admin API legitimately returns, including OIN catalog apps. Concretely:

1. AUTO_CONFIRM_IMPORTS is added to the Application.features enum. More robustly: an unrecognized feature value should not fail deserialization at all, since Okta ships features faster than SDK releases.
2. BrowserPluginApplication.name accepts OIN catalog template names, and the SwaApplicationSettingsApplication fields become optional.

Steps to reproduce

1. pip install okta==3.4.4
2. Run the snippet above — no Okta tenant or API token required.
3. Observe both value_error failures.
4. Optionally, against a live tenant containing any OIN catalog SWA app, or any custom SAML app with SCIM provisioning: apps, resp, err = await client.list_applications(limit=200) returns apps is None.

References

• list_applications produces pydantic validation errors for SamlApplication #546 — missing StrictBool fields on SamlApplicationSettingsSignOn. Tracked separately; deliberately out of scope here.
• fix: remove required constraints from SamlApplicationSettingsSignOn schema #542 — the merged PR closing list_applications fails to deserialize responses when any SAML app omits required signOn fields #536, which relaxed the ten StrictStr fields and intentionally left the five booleans required
• list_applications fails to deserialize responses when any SAML app omits required signOn fields #536, Pydantic Models Reject Valid Empty String Values #481, Overly restrictive validation on objects (such as AppUser ) when used in reference requests. #498, assign_user_to_application docs mark AppUser.profile as optional, but function fails without it and requires dict input #479 — prior instances of the same overly strict generated validation
• okta/models/application.py::features_validate_enum — the 42-value enum
• okta/models/browser_plugin_application.py — the name enum
• okta/models/swa_application_settings_application.py — the required settings.app.* fields
• okta/api_client.py::__deserialize — validates a page in one comprehension, so one bad app fails all
• Downstream impact: cartography#1243 (Okta module migration to okta>=3.4.0) cannot enumerate applications until these and list_applications produces pydantic validation errors for SamlApplication #546 are resolved

[jasonhernandez]

Scope note: this issue originally also covered the five missing StrictBool fields on SamlApplicationSettingsSignOn. That is already tracked in #546 (open, with independent corroboration on 3.4.4), so I have edited it out of the description to keep #546 as the single thread for it.

What remains here are the two defects that are not reported elsewhere — the Application.features enum missing AUTO_CONFIRM_IMPORTS, and BrowserPluginApplication rejecting OIN catalog SWA apps. Both are isolated from #546 in the reproduction: the SAML payload has a fully populated signOn block, and the SWA payload is a different sign-on mode entirely.

The reason they are worth tracking separately rather than folding into #546: in the tenant I measured, 6 of the 39 deserialization failures come from these two defects and would persist after #546 is fixed. Since __deserialize validates a page in one comprehension, those 6 are still enough to make list_applications return None for all 50 apps.