ListApplications does Not return client_id for oidc_client's

[bfrisbie-brex]

Describe the bug?

Calling the ListApplications function in the Golang SDK returns a list of Applications as expected. However, metadata about these applications are missing from the results.

In particular, OIDC clients/application do Not have their client ID's listed in the results. This is in contrast to calling {{url}}/api/v1/apps?q=oidc_client via Postman, which does contain the client ID's.

Example output from the Golang SDK ListApplications call:

    "apps": [{
        "_links": {
            "appLinks": [{
                "href": "https://<URL_REDACTED>/home/oidc_client/0oa3dpxo1bhwkyeZf1d7/aln177a159h7Zf52X0g8",
                "name": "oidc_client_link",
                "type": "text/html"
            }],
            "clientCredentials": [{
                "href": "https://<URL_REDACTED>/api/v1/apps/0oa3dpxo1bhwkyeZf1d7/credentials/secrets",
                "name": "secrets"
            }],
            "deactivate": {
                "href": "https://<URL_REDACTED>/api/v1/apps/0oa3dpxo1bhwkyeZf1d7/lifecycle/deactivate"
            },
            "groups": {
                "href": "https://<URL_REDACTED>/api/v1/apps/0oa3dpxo1bhwkyeZf1d7/groups"
            },
            "logo": [{
                "href": "https://op3static.oktacdn.com/assets/img/logos/default.6770228fb0dab49a1695ef440a5279bb.png",
                "name": "medium",
                "type": "image/png"
            }],
            "uploadLogo": {
                "hints": {
                    "allow": ["POST"]
                },
                "href": "https://<URL_REDACTED>/api/v1/apps/0oa3dpxo1bhwkyeZf1d7/logo"
            },
            "users": {
                "href": "https://<URL_REDACTED>/api/v1/apps/0oa3dpxo1bhwkyeZf1d7/users"
            }
        },
        "accessibility": {
            "selfService": false
        },
        "created": "2022-04-01T18:58:15Z",
        "credentials": {
            "signing": {
                "kid": "2bhPaIJTek5waGQkp5jz_pkLaIBuTYtUa3uIke8KKns"
            },
            "userNameTemplate": {
                "template": "${source.login}",
                "type": "BUILT_IN"
            }
        },
        "id": "0oa3dpxo1bhwkyeZf1d7",
        "label": "Sample Client",
        "lastUpdated": "2022-04-01T18:58:16Z",
        "name": "oidc_client",
        "profile": {
            "label": "Sample Client"
        },
        "settings": {
            "app": {},
            "notes": {
                "admin": null,
                "enduser": null
            },
            "notifications": {
                "vpn": {
                    "network": {
                        "connection": "DISABLED"
                    }
                }
            }
        },
        "signOnMode": "OPENID_CONNECT",
        "status": "ACTIVE",
        "visibility": {
            "appLinks": {
                "oidc_client_link": true
            },
            "autoLaunch": false,
            "autoSubmitToolbar": false,
            "hide": {
                "iOS": true,
                "web": true
            }
        }
    }]

What is expected to happen?

ListApplications should include client ID's for OIDC apps.

What is the actual behavior?

It does not.

Reproduction Steps?

Call ListApplications in an env containing at least one OIDC app.

Additional Information?

No response

Golang Version

go version go1.17.6 darwin/amd64

SDK Version

github.com/okta/okta-sdk-golang/v2 v2.10.1

OS version

No response

[laura-rodriguez]

Hi @bfrisbie-brex,

Thanks for reporting this. Someone from our team will review it soon.

cc @monde

[monde]

Hi @bfrisbie-brex , I missed seeing this issue. I can see what is going on, it is a side of effect from the general way the golang code is generated for the various list endpoints and golang serialization. In this case, the generated code for list applications is minimal, the response gives a slice of the base application model. But as you point out, there can be specific models in the response, like an oidc application. Both models have credentials, but when an oidc model is returned in the list it is done so as a base application which does not have oidc credentials , just base application credentials.

I don't see this getting fixed in the v2.x.x version of the okta-sdk-golang. We are working on a new way to generate all of the SDK clients and that will be released as a v3 version, probably in the next quarter. I'm not certain if the behavior will be corrected then, but I will keep this in mind as, as I said, all of the list endpoints that have specialized models exhibit this behavior.

As a work around, once you have the id of the oidc application you are interested in, can you do a subsequent get for that application with the correct model type? Like this test code for GetApplicaton but change that from a basic auth application to an oidc application with okta.NewOpenIdConnectApplication()?

[bfrisbie-brex]

@monde Thank you for your detailed and thoughtful reply 🙂
I agree with your description about what's happening. 👍

I think the workaround you suggested should work for my team's needs, because our services will call ListApplications pretty infrequently. I'm following up with my team to see if they have any concerns, but for the time-being you can assume we will use the workaround until the glorious day when a single call to ListApplications will suffice. 👍

[minwan]

@monde thanks for the reply, but the workaround does not work for us given we have thousands of applications. The context is we are migrating our API access management stack to Okta (with Enterprise version) and need a feature parity to list all applications and client id is the key for those applications. Is it possible to do a patch / schema update in V2?

[monde]

@minwan can you open a support ticket https://support.okta.com/ so it is escalated internally for prioritization?

[minwan]

thanks opened case 01383954

[github-actions]

This issue has been marked stale because there has been no activity within the last 14 days. To keep this issue active, remove the stale label.

[monde]

Additional notes:
clientId is on the profile property
https://developer.okta.com/docs/reference/api/apps/#oauth-2-0-based-provisioning-connection-profile-example .

profile property is defined as an object on the Application model https://github.com/okta/okta-management-openapi-spec/blob/master/resources/spec.yaml#L9292-L9346

When generated to golang code profile becomes an interface{}. So we'd need to have something like ApplicationProperty in the openapi spec to surface clientId and authScheme

[monde]

Golang code generation needs to have a specific case for ListApplications https://github.com/okta/okta-management-openapi-spec/blob/master/resources/spec.yaml#L31-L82 . When generating the ListApplications method it needs to inspect the name property on each application listed and look up the correct type to use in the output. We already do some juggling like this on operationId in the defaultMethod template https://github.com/okta/okta-sdk-golang/blob/master/openapi/generator/templates/model/defaultMethod.go.hbs#L35

[monde]

ping, me