# Konnect App Auth > Use when Konnect Dev Portal APIs are published but blocked by application auth strategy, registration, approval, or app-credential flow issues; not for Portal sign-in/SSO or basic API publication. - **Type:** Skill - **Install:** `agentstack add skill-kong-ai-marketplace-konnect-app-auth` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Kong](https://agentstack.voostack.com/s/kong) - **Installs:** 0 - **Category:** [Security](https://agentstack.voostack.com/c/security) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Kong](https://github.com/Kong) - **Source:** https://github.com/Kong/ai-marketplace/tree/main/plugins/kong-konnect/skills/konnect-app-auth - **Website:** https://konghq.com ## Install ```sh agentstack add skill-kong-ai-marketplace-konnect-app-auth ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Konnect application auth workflow ## Goal Help an operator configure or troubleshoot how developers register applications, receive credentials, and use APIs through Konnect Dev Portal and Konnect Application Auth. Own the application-auth branch only: strategy choice, application registration, approvals, credentials, and the publication-to-enforcement path. Do not keep Portal sign-in, SSO, or generic API publication diagnosis in this skill after the surface is classified. ## Tool Selection - Use the shared `kong-konnect` MCP server first for live inspection of portals, publications, application auth strategies, applications, registrations, and related approvals. - Preserve the repository's chosen declarative toolchain when auth resources need to change: use `terraform-konnect` for HCL-managed resources and `kongctl-declarative` only when the surrounding repo already uses `kongctl` for this Konnect workflow. - Use `deck-gateway` only when the real change is downstream Gateway-entity config rather than Portal app-auth configuration. - If live Konnect state matters and `kong-konnect` MCP is not connected, say so early and continue with user-provided artifacts or repo context. - If the primary issue is developer sign-in, SSO, or broad org/team access, classify that early and stop instead of debugging app credentials here. ## References To Load Load only the reference file that matches the active branch: - `references/auth-strategy-selection.md` - Load when choosing between key auth, self-managed OIDC, and DCR is the main decision. - `references/registration-and-approval-flows.md` - Load when the strategy is plausible but self-service, approvals, or registration state still block developers. - `references/linked-service-and-enforcement.md` - Load when the hard question is whether auth can actually be enforced on the linked Gateway Service path. ## Inspection Order ### 1. Classify the failing surface before choosing fixes Clarify whether the problem is: - developer sign-in or SSO into the Portal - application creation or registration approval - API-specific registration - credential issuance - runtime authorization at the linked Gateway Service Do not use one answer path for all of these. If the blocker is mainly Portal sign-in or non-app-specific access, stop and hand off before investigating app registrations or credentials. ### 2. Verify the publication-to-enforcement chain For developer self-service to work as intended, inspect: - application auth strategy existence - API linkage to a Gateway Service - API publication to the intended Portal - auth strategy selection on that publication If any link is missing, stop there before debugging credentials. Load `references/linked-service-and-enforcement.md` when the chain appears complete on the portal side but runtime enforcement still looks wrong. ### 3. Choose strategy by client-ownership model Choose based on who creates and owns the client credential material, not on which option happens to be easiest to name in the UI. Keep the strategy choice separate from publication state or downstream Gateway enforcement. Load `references/auth-strategy-selection.md` when the main question is which strategy model fits the intended developer workflow. ### 4. Inspect approvals, registration state, and consumption gates If the strategy is correct but access still fails, inspect: - whether developer approval is required - whether application approval is required - whether the registration is pending, approved, revoked, or rejected - whether team or RBAC assignment is blocking consumption Treat “published but unusable” as a workflow-state problem until proven otherwise. Load `references/registration-and-approval-flows.md` when pending, approved, rejected, or RBAC-gated state is the likely blocker. ### 5. Prove the linked-service enforcement boundary Application auth only works the intended way when the API is linked to a Gateway Service and the auth strategy can be enforced there. If there is no linked service, or the wrong service is linked, fix that model before changing strategy details. ### 6. Return the narrowest failure point and next owner Classify the primary issue as: - missing auth strategy - wrong strategy type for the use case - missing Gateway Service linkage - missing or mis-scoped publication - approval / registration state mismatch - RBAC or team assignment mismatch ## Konnect-Specific Gotchas - User auth and application auth are different layers. - Selecting an auth strategy during publication applies it to the linked Gateway Service path, not just to Portal presentation. - A Gateway Service must be linked for auth strategies to be enforced as intended. - One application can use only one auth strategy at a time. - Published APIs can still be unusable because approvals, registrations, or linked-service enforcement are incomplete. ## Validation Checklist Before answering, verify that you can state: - which surface is actually failing: Portal sign-in, app auth, registration, approval, or runtime enforcement - whether the publication-to-enforcement chain is complete end to end - whether the selected strategy type matches the intended developer flow - whether approvals or RBAC are the real blocker - what exact object or state proves the diagnosis - whether another skill should own the next step ## Handoffs - Use `konnect-api-publish` when the API is not yet published or is published to the wrong audience. - Use `konnect-api-catalog` when the API or implementation model itself is not ready. - Use `konnect-access-scope` when the problem is mainly who can view or administer the Portal or auth resources, or when org/team/role scoping is broader than one app-auth workflow. - Treat developer Portal sign-in or SSO problems as Portal identity work, not application-auth work. - Use `terraform-konnect` or `kongctl-declarative` when the operator wants to encode or apply the resulting auth changes as config. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Kong](https://github.com/Kong) - **Source:** [Kong/ai-marketplace](https://github.com/Kong/ai-marketplace) - **License:** MIT - **Homepage:** https://konghq.com Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-kong-ai-marketplace-konnect-app-auth - Seller: https://agentstack.voostack.com/s/kong - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.