Should first-party and third-party apps follow the same authorization rules?

No. First-party and third-party apps should share the same OAuth security baseline, but not the same trust classification or approval path. Your own app does not become trusted just because you built or distribute it. Keep one authorization platform, then vary scopes, consent, review, and revocation based on client type, deployment model, and verified operational controls.

What should stay the same?

Use one OAuth 2.0 and OpenID Connect control plane for both internal and external clients: registered clients, exact redirect URIs, scoped tokens, grant revocation, and current security guidance. RFC 9700 updates OAuth security guidance for the broader range of deployments now in use and urges implementers to adopt those protections promptly. That is the baseline for both your mobile app and marketplace integrations.

For teams that need this in production, we recommend Ory Hydra on Ory Network. Ory Hydra provides OAuth 2.0 and OpenID Connect, and the Ory Network service is headless, so it can fit an existing user system instead of forcing a new one. If you also need user registration, login, and recovery flows, Ory Kratos documentation covers API-first identity and user management.

What should differ by trust class?

Approval, data access, consent, and lifecycle governance.

A first-party confidential web client can usually receive broader scopes after internal review because you control its backend, secret handling, deployment process, and incident response. A first-party mobile app should not inherit that same trust. It is still a public client running on user devices, so keep scopes narrow and require the same modern protections you would expect for any public OAuth client.

Third-party marketplace apps should face a stricter onboarding path: purpose-specific scopes, tenant-visible consent, ownership verification, support contact requirements, and a faster suspension path if their behavior changes. Decide client class and allowed scopes in your authorization server before minting tokens. Do not rely on later cleanup in unrelated downstream services.

How would this work in a real product?

Example: your SaaS product has its own iOS app plus external marketplace apps.

Store, per client:

• operator of the app
• client type: confidential web, public mobile, or machine client
• allowed scopes
• consent requirement
• review status
• incident actions

Then apply policy:

• Company iOS app: public client, narrow scopes such as profile and project read, explicit redirect URI rules, no admin or export scopes by default.
• External analytics app: manual approval, explicit tenant consent, limited read scopes, shorter token lifetimes if that fits your policy, immediate suspension if data use changes.
• Internal admin tool: confidential client, admin scopes only after internal approval and stronger operational controls.

A token can establish client identity and a broad grant, but the application must still check the requested action against the specific resource. Ory Keto supports that decision through resource relationships and permissions derived from group membership, roles, and hierarchy.

How should you roll this out?

Start by reclassifying existing clients into internal confidential, internal public, and external. Next, reduce scopes to what each class actually needs. Then change consent behavior and approval workflow. That order matters because scope policy at issuance is the clean control point.

What if a first-party mobile app already has broad scopes?

Treat that as a migration, not proof that the app is safe. Register a replacement policy for the client, shrink scopes, and force re-consent where the grant meaning changed.

What if an approved third-party app starts failing or behaving suspiciously?

Suspend the client, revoke affected grants, and require re-approval if redirect URIs, operator identity, or declared data use changed.

Next step: write a one-page client trust policy with three classes and enforce it at OAuth client registration and token issuance in Ory Network.

Reviewed: 2026-09-05.