Authentication and Authorization

This article explains how custom applications authenticate with Flowlu, how user identity is determined, and how authorization is enforced when applications access the Flowlu API.

Understanding these concepts is essential for building secure and predictable applications.

Supported authentication methods

Flowlu supports the following authentication methods for custom applications:

• OAuth 2.0

• API keys

These methods serve different purposes and should be used accordingly.

User identity and request context

User identity in Flowlu is determined only by an OAuth 2.0 access token.

When an application sends an API request with an OAuth access token, the request is executed on behalf of the user to whom that token belongs.

API keys do not represent a specific user identity. They are intended for system-level or service access where user context is not required.

OAuth 2.0: when and why to use it

OAuth 2.0 should be used when an application needs to act on behalf of a specific user, for example:

• when performing actions initiated by a logged-in user,

• when respecting user-level permissions,

• when displaying or modifying user-specific data.

When OAuth 2.0 is used, the application includes the user’s access token in the request headers. The API request is then executed using that user’s permissions and access rights.

Frontend API requests and the JS SDK

Custom applications may send API requests from frontend code.

When an application is embedded into the Flowlu interface and uses the Flowlu JS SDK, all frontend API requests are automatically executed using the access token of the currently authenticated user.

This is the recommended and safest approach for frontend API access.

Important security recommendation

Frontend API requests should only use the access token of the current user.

Because frontend code runs in the browser, request data — including tokens — can be inspected using browser developer tools. If a frontend request uses a token belonging to a different user, the current user could intercept and misuse that token.

For this reason:

• frontend requests must always run under the current user’s identity,

• tokens belonging to other users must never be exposed in frontend code.

Backend API requests

Applications may also send API requests from their backend services.

Backend requests may use access tokens of different users if required by the application’s business logic. In this case, the developer is responsible for:

• securely storing access tokens,

• ensuring tokens are used only for their intended purpose,

• preventing unauthorized access.

Backend services are the correct place for:

• sensitive operations,

• background processing,

• cross-user or administrative logic.

Permissions and authorization

API access is restricted by permissions declared in the application’s manifest.

Permissions define which API operations an application is allowed to perform. All API requests are validated against:

• the permissions approved during application installation, and

• the access rights of the user whose token is used.

If an application attempts to perform an action outside its granted permissions, the request is rejected automatically.

Summary

• Flowlu supports OAuth 2.0 and API keys for custom applications.

• User identity is determined only by OAuth 2.0 access tokens.

• API requests are executed on behalf of the user whose token is provided.

• The Flowlu JS SDK always uses the current logged-in user’s token.

• Frontend requests must only use the current user’s token.

• Backend services may use other tokens but must manage them securely.

• All requests are limited by permissions declared in the application manifest.

For implementation details, token handling, and endpoint reference, see the Flowlu API documentation.