Authenticate clients and authorize users

Authentication establishes who is calling; authorization decides what that caller may do. A Cloudgate application can require both gateway integration access and an app-user identity.

Browser-to-workflow flow#

User signs in through the supported IdP flow
    → app obtains its session
    → request includes Authorization: Bearer <token>
    → gateway access checks run
    → IdP Authorize validates the user
    → business logic checks ownership and permissions

Configure CORS for the browser origin when needed. CORS permission, a valid gateway signature, and a valid user token answer different questions.

Use the authorized identity#

Name the IdP Authorize node clearly, such as IdpAuth. For a User ID output, use ${IdpAuth} when querying the caller's records. Remove redundant caller-controlled user IDs from the public contract unless an authorized administrative operation explicitly needs them.

If the workflow forwards a token to another service, confirm that service accepts that token's issuer, audience, and purpose. A token valid for one system is not automatically valid for another.

Server applications#

Use the configured gateway authentication for server integrations. If an operation acts on behalf of an app user, preserve the user authorization contract as well. A server credential alone should not silently select an arbitrary user account.

Test real authentication#

Some internal development sample requests bypass IdP authorization and report that mode. They help test business logic but do not prove a public browser request will work. Run a separate public request with a real session and verify the response.

Test missing, expired, invalid, and insufficiently privileged tokens. Expect authentication failures to prevent downstream work. Do not fix a failing test by enabling anonymous access on a private workflow.

See API access, identity nodes, and CORS.