How Flowable REST API authentication works and when teams need to configure it
If your Flowable REST application is reachable from other systems, a front end or a partner integration, the first question is who is calling and what they may do. The REST application answers that question by checking the credentials on each request, typically with HTTP basic authentication sent over HTTPS, and then matching the caller to a user in the engine's identity service. That user must also hold the rest-access-api privilege before the REST endpoints accept the request. Teams that only run Flowable embedded inside their own application, with no REST layer exposed, may not need this configuration at all. Teams that expose the REST application to anything beyond a private network need to plan it before go-live.
Several specifics govern how this behaves: how the REST application validates users, whether the verify-privilege and any-user modes are in effect, and which identity source backs the users. These behaviors are set through configuration and differ between Flowable versions, so confirm each setting against the documentation for the version you run. The Flowable docs on configuration are the natural starting point, and the Flowable docs on getting started describe the REST application as one of the ways to run the engine. Read the release notes for your version too, since the Spring and Jakarta baseline changes between major releases and can alter how security filters are wired.
Before exposing the REST application, make three decisions: who your callers are and which privileges each needs, whether basic authentication over HTTPS is acceptable for their traffic, and whether you will eventually need token-based access from clients you do not control. Run a test in a non-production environment that confirms an unauthenticated request is refused, a caller without rest-access-api is refused, and a valid caller gets only the data they should see. Note that the engine checks privileges, but it does not decide which process instances or tasks a given user owns, so that layer belongs to your application.
Authentication modes and privilege settings compared
This table compares the built-in REST authentication modes in Flowable with a token-based approach placed in front of the engine. Read each row for what the option allows, who it suits and the main trade-off in control or complexity. The main takeaway is that basic authentication with the verify-privilege mode is the baseline to start from, and tokens fit when you need federated identity or many client applications.
| Option | What it allows | Who it suits | Main trade-off |
|---|---|---|---|
| Basic authentication over HTTPS | Callers send user credentials with each request, checked against the engine's identity store. | Teams wiring scripts or internal services to the REST API during early integration. | Credentials travel on every call, so HTTPS must be enforced and password storage must be secured. |
| Verify-privilege mode | Only users holding the rest-access-api privilege can call the REST endpoints. | Deployments that should limit REST access to named accounts with an explicit grant. | Privileges must be granted and reviewed per user, and they do not limit what each record a user may change. |
| Any-user mode | Any identity the engine authenticates can call the REST endpoints without the privilege check. | Isolated test environments, or where a gateway already restricts who can reach the API. | Authentication becomes the only gate, so one over-provisioned account has broad REST reach. |
| Token-based approach in front of the engine | Callers present short-lived tokens issued by an identity provider and validated at a gateway or proxy. | Organizations with several client applications, federated users or frequent credential rotation. | Confirm whether your version accepts bearer tokens directly, or whether you must map claims to Flowable identities yourself. |
| Dependency on the identity store | Every mode above checks identities held in the engine's identity tables or an external identity service. | Any deployment, since the modes are only as strong as the accounts behind them. | Default accounts and plain-text password storage weaken every option, so address them first. |
| Configuration to confirm | The exact property names, mode values and privilege names for your Flowable version. | Platform and security engineers preparing the configuration for review. | Property names change between major versions, so check the Flowable configuration docs for your release. |
Setting up REST authentication in a Flowable deployment
This sequence takes a Flowable REST deployment from an unknown baseline to one where every call is authenticated over HTTPS, only named users with the rest-access-api privilege can call the endpoints, and the chosen verify-privilege or any-user mode is confirmed by testing. Each step closes with a check you can record as evidence.
Confirm the REST application and starter version
The platform team confirms which Flowable line and framework baseline the deployment uses before changing any security setting. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, while the 7.x line runs on Spring Boot 3 and Jakarta EE. Read the Flowable 8.0.0 release notes and check the resolved dependency tree in your build. Done when the Flowable and Spring Boot versions in the running artifact match the versions you have written down for the security review.
Enable HTTPS in front of the endpoints
The infrastructure team terminates TLS at a reverse proxy, load balancer or the servlet container, and the application is reachable only through that HTTPS listener. Basic authentication sends the username and password in a reversible encoding, so plain HTTP must not be available to clients or to any network segment outside the engine's trust zone. Confirm that the certificate chain is valid from a client machine and that the plain HTTP port is closed or redirected. Done when a request sent over HTTP never reaches the REST application and an HTTPS request returns a response from it.
Create named users for each caller
The identity administrator creates one account per person or per integration client, using the identity source your deployment uses. Keep the default rest-admin account out of any environment that is reachable from a network, and do not share credentials between callers. If identities live in an external directory, confirm with your Flowable version's identity documentation how the REST layer resolves those users, because identity management can be replaced with a custom identity service. Done when the list of REST users matches an approved roster and each user can authenticate with their own password.
Assign the rest-access-api privilege
The administrator grants the rest-access-api privilege only to the users and service accounts that need REST access, and records who approved each grant. Assignment is made through the privilege administration available in your deployment, so confirm the exact admin path for your version before you start. A user with valid credentials but without this privilege should be refused, which is the behavior the later tests rely on. Done when one granted user and one ungranted user with valid passwords produce different results on the same endpoint.
Select verify-privilege or any-user mode
The platform owner chooses the access mode for the REST application. In verify-privilege mode, the engine checks that an authenticated user holds rest-access-api before serving the request. In any-user mode, any authenticated identity can use the REST API, which removes the per-user privilege check. Confirm in the Flowable configuration documentation how the mode is set in your version, record the setting in configuration under version control, and restart the application. Done when the running configuration shows the chosen mode and the change is recorded with the reason for the choice.
Test that unauthenticated calls are refused
The security engineer sends requests to a small set of REST endpoints with no credentials, with a wrong password and with an unknown user name. Each request should be refused with an authentication error, and no process data should appear in the response. Run the same calls over HTTPS only, since the test should match the path real callers use. Save the requests and responses as evidence. Done when every unauthenticated or invalid-credential call is refused and the saved results list the endpoint, the input and the refusal.
Test that unprivileged calls are refused
The security engineer signs in as a user who has valid credentials but no rest-access-api privilege, then calls the same endpoints used in the previous test. In verify-privilege mode, these calls should be refused with an authorization error. If the test is run in any-user mode, the expected result is different, so record the mode next to each result. Repeat the test with a privileged user to confirm that the same endpoints still work. Done when the unprivileged user is refused, the privileged user succeeds, and both outcomes are saved with the mode and the test date.
Security risks in basic authentication over Flowable REST
Basic authentication is the simplest way to call the Flowable REST API, and it is also the one most likely to be left in place unexamined. The cards below cover the transport, account, storage and authorization risks that tend to appear together when an engine is exposed beyond its own network. Each one has a control or check you can confirm in your environment before the REST application receives traffic from other systems.
Credentials sent on every request
Basic authentication sends the username and password encoded in each HTTP request header, so the credential is reused on every call rather than exchanged once. Any log, proxy or debugging tool that records headers can capture it. Check your gateway and application logs for Authorization headers, and confirm that your HTTP client libraries and monitoring agents redact them before anything is written to disk. Each call carries the password, which is why the token question matters once several services call the engine.
Plaintext exposure without HTTPS
Basic credentials are base64 encoded, which is an encoding, not encryption, so anyone who can read the traffic can recover the password. Terminate TLS at the REST application or at a reverse proxy in front of it, and block plain HTTP on the listening port. Verify this by capturing a request from a client segment and confirming that the connection is encrypted end to end, including any internal hop between the proxy and the engine.
Shared accounts across callers
When several services or people use one REST login, the engine cannot tell them apart in history, audit data or failed-login counts, and a single password change breaks every integration at once. Assign one account per calling system, give each the narrowest group and privileges it needs, and record which system owns each account. Ask your team to list every account with the rest-access-api privilege and name an owner for each one.
Default demo credentials left active
Flowable's examples and Docker images include a default rest-admin user, and any environment started from those samples can expose it. Before the REST application is reachable from another network, confirm that the default account is removed or its password changed, and that no sample or test data is loaded into production schemas. Add a deployment check that fails if the default user still exists, so the control survives future rebuilds.
Password storage in IDM tables
When the identity management engine holds users, passwords are stored in its database tables, and an older or default configuration may keep them in a form that can be read directly. Query the IDM user table in a non-production copy to see how passwords are stored, and confirm that a password encoder is configured before go-live. If identities live in LDAP or an identity provider, confirm that the IDM engine is not also issuing REST credentials.
Authenticated is not authorized
Passing basic authentication only proves who is calling, not whether that caller may act on a particular task, process instance or case. The REST layer checks privileges by endpoint, but candidate groups, identity links and tenant boundaries are your application's responsibility to enforce. Write tests that call each endpoint as a user without rights to a given object, and confirm that the request is refused with a 403 response and an audit entry.
When to replace basic auth with tokens on Flowable REST
Replace basic auth with tokens when the callers stop being a small, known set of internal clients. Basic authentication sends the same username and password with every request, so every service that calls the Flowable REST API holds a long-lived credential that is only as safe as its storage. That model is workable when a handful of back-end services call the engine from a controlled network. It becomes hard to defend when many services or end-user sessions reach the engine, because each new caller multiplies the places a password can leak, and rotating one shared password means coordinating every consumer at once. If credential rotation, short-lived access or per-user revocation matter to your control framework, tokens are the usual direction.
A second signal is whether your organization already runs an identity provider that issues tokens. If users sign in through an OIDC or SAML provider for other applications, routing Flowable access through that same sign-in usually gives you central lockout, MFA enforcement and offboarding in one place. The Flowable REST application does not, on its own, hand you that federation, so the token check typically sits in an API gateway or in the application layer in front of Flowable. Treat that as an application or gateway design decision. Before you commit, confirm with your Flowable version's documentation and your gateway vendor exactly how bearer tokens are validated, which claims map to Flowable privileges, and whether the REST application accepts them directly or only through a proxy you build.
Basic auth can remain acceptable for internal, tightly controlled callers: a small number of named service accounts, traffic that stays on a private network with TLS enforced, a separate least-privilege user per integration, and a documented rotation procedure. Write down that decision along with the callers it covers, because it is the first thing an auditor will ask about. Whichever path you choose, verify it with a test: confirm that an expired or revoked credential is refused, that a caller without the rest-access-api privilege gets no data, and that the gateway cannot be bypassed to reach the engine directly.
Limits to confirm before exposing the REST API
The REST API's authentication model depends on the Flowable version, the identity service behind it and the endpoints published next to it. Confirm these four limits in your own environment before any endpoint is reachable from outside the trusted network, because a change in one of them can alter who gets in.
Flowable version and Spring Boot baseline
Confirm which Flowable line you run before you read any privilege or configuration guidance. Flowable 8.0.0 was released on February 27, 2026, and its release notes move the baseline to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. Flowable 7.x runs on Java 17 and Spring Boot 3. Check the Spring Boot version, the Jackson library and the security filter configuration against the version you deploy, because security settings written for one baseline may not load on another.
Built-in IDM or replacement identity service
Establish where your callers are defined before you choose an authentication mode. If the built-in IDM engine holds the users, basic authentication checks passwords against its tables, which is why password storage matters. If you replaced the identity service, for example with an LDAP-backed implementation, the REST checks depend on your replacement, so confirm how it authenticates users and which groups and privileges it returns.
Supported database types
Confirm the database your engine and identity tables use, since the authentication data lives there. Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types. Test your chosen database with the same user, privilege and lock behavior you expect in production, and confirm the MySQL version if you use MySQL, because versions below 5.6.4 lack millisecond precision.
Whether any-user mode is acceptable
Decide whether any-user mode is acceptable before you enable it. In this mode the REST API accepts requests without verifying that the caller holds the rest-access-api privilege, so anyone who can reach the endpoint may read and change engine data. Most deployments should keep the verify-privilege behavior and grant the privilege only to named service accounts. Document the decision, the network path and who approved it.
Actuator and other endpoints exposed
Check which endpoints the application publishes alongside the REST API. The Flowable Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes, and other framework endpoints may be enabled by default in your application. List every published path, its authentication requirement and its network reach, then restrict or remove anything that is not needed for operations before the REST API is reachable.
Questions buyers ask about Flowable REST authentication
What does it cost to harden Flowable REST authentication?
Cost depends on how many REST access points you expose, how many identity sources you must connect and how much of the surrounding infrastructure you must change. The main cost components are the time to design the privilege model, the configuration and testing work in your non-production environments, and the change control and verification before go-live. Most of this is one-time work. Recurring costs appear when you add new REST clients, rotate credentials or upgrade Flowable. Ask any provider for a quote built from a written scope that lists the endpoints, environments and identity sources involved, not a flat rate for 'securing Flowable'. DeployOpen does not publish a price list, and a quote follows from the agreed scope.
Which parts of the work drive the effort most?
The largest effort drivers are usually the identity source, the number of REST clients and the number of environments that must be aligned. A deployment that authenticates against one directory with a few service callers is far simpler than one where human users, batch jobs and third-party systems each need different privileges. Effort also rises when existing process applications call the REST API with shared accounts that must be split up before the change can be made safely. Verification effort grows with the number of privileges your applications rely on, because each one must be tested for both allowed and denied calls.
How long does a typical hardening change take?
Duration depends on scope, and no fixed figure applies to every Flowable deployment. A narrow change, such as replacing the default administrator with a named account and confirming that HTTPS is enforced, moves quickly. A broader change that adds a new identity source, redesigns privileges across several applications and updates CI pipelines takes longer because each step needs testing. Ask for a timeline tied to a written list of deliverables, and check whether it assumes that identity, network and certificate teams are available when needed.
What must our team provide before the engagement starts?
You should provide several inputs before work begins. These are the identity source that will authenticate callers, such as an LDAP directory or an identity provider, along with the group structure that maps to Flowable privileges. You also need to confirm where HTTPS terminates, whether at a load balancer, ingress controller or the application server, and who manages those certificates. Access to non-production environments that mirror production, a list of every system that calls the REST API, and a named owner for change approval are equally important. Missing any of these usually extends the timeline more than the technical work itself.
Can our internal team replace basic authentication on its own?
An experienced internal platform or identity team can make these changes alone if it has Flowable and Spring knowledge, access to the identity source and a test environment that matches production. The areas most often underestimated are the privilege model, which must be checked against every application that calls the API, and the token design if you move beyond basic authentication. Teams new to Flowable often find the time to review existing callers is the hardest part. Decide early whether you have the capacity to do that review, and whether someone will own the result after handover.
When does a retainer or fixed-scope review make more sense?
A fixed-scope review suits organizations that want an independent check of an existing deployment before an audit, a migration or a change in identity provider. It produces findings and a written remediation plan that your team can execute. A fixed-scope implementation suits a defined change, such as moving from basic authentication to tokens for a known set of clients. A retainer makes sense when the REST API keeps changing, new applications are added regularly, or upgrades must be planned against each Flowable release. Retainers carry recurring cost, so compare that against the cost of re-running a one-time project after each change.
What should engineers check after basic authentication is enforced?
Engineers should confirm that unauthenticated requests are rejected on every REST path they expose, that the account used by each caller holds only the privileges it needs, and that credentials never appear in logs or in client-side code. Test the verify-privilege and any-user modes against the behavior you intend, because a setting that looks restrictive can still allow more than you expect. Confirm that the endpoints that were deliberately excluded remain unreachable from outside the network. Record the results so that auditors and future upgrades can compare against a known baseline.
Does the Flowable open source license restrict this work?
Flowable's open source engines are licensed under Apache 2.0, which permits you to configure and extend them in your own infrastructure. Confirm with your legal team how the license applies to any modifications you make and to any commercial Flowable products you may add, because those products are built on the same engines but are offered under separate terms. Check the current licensing text in the project repository before committing to a design.
How the REST authentication scope is agreed before work starts
Before any configuration changes, a fixed-scope engagement for Flowable REST authentication fixes four inventories in writing: the REST endpoints in use, the identity sources that will authenticate callers, the privilege assignments each caller receives, and the test evidence that will show the result. DeployOpen uses these inventories as the scope of work, so the reader can see what is changed and what is left alone. For the endpoint list, the team must decide which REST paths are reachable from which networks, whether the actuator endpoint at /actuator/flowable is exposed at all, and whether the rest-access-api privilege is granted only to service accounts that need it. For identity sources, the agreement should name whether users live in the engine's IDM tables, in LDAP or in an identity provider, because that choice decides who owns password policy and offboarding.
The privilege inventory is where most surprises appear. Each application or integration that calls the REST API should map to one named account or client, with the verify-privilege and any-user behavior documented for every endpoint it touches. Ask the team to confirm the Flowable version in use before the inventory is drawn up, since the REST API surface and the Spring baseline differ across releases, and check the current Flowable documentation for the exact property names rather than relying on memory. The test evidence should cover both positive and negative calls: a caller with the right privilege succeeds, and a caller without it receives a refusal on every endpoint in the inventory. Any gap found during testing should be logged as a scope change with a written decision, not fixed silently. Ongoing support after the initial work is available as a retainer, which can cover re-running the inventory after upgrades, reviewing new endpoints and rotating credentials. Whether it is worth it depends on how often your team adds process applications and how many systems call the engine. Ask any partner, including DeployOpen, to state in the quote which items are one-time, which recur, and who owns each inventory after handover.
How DeployOpen scopes, delivers and supports Flowable REST security
DeployOpen works on Flowable REST API authentication as part of a written scope that names the endpoints, identity source, privileges and HTTPS setup in your environment. We build and test the configuration inside your own infrastructure, then document and hand it over so your team can run it.
How we scope
- Inventory which Flowable REST endpoints your applications and integrations call, and which must stay closed.
- Confirm the identity source for REST callers, whether the built-in identity tables, LDAP or another provider.
- Define the rest-access-api privilege assignments, verify-privilege mode and any-user behavior in the written scope.
- Agree in writing whether the scope covers basic authentication only or a later move to token-based access.
How we build
- Configure HTTPS termination and basic authentication settings in the deployment you control, not in demo defaults.
- Remove or lock the default REST admin account and test that unauthenticated and under-privileged calls are refused.
- Test each privilege level against the endpoints it should and should not reach, using scripted requests.
- Keep configuration in version control so changes to REST access go through review.
How we hand over
- Deliver a written record of the authentication mode, privilege map, accounts created and the test results.
- Document how to add or remove REST users and privileges, and who in your team approves those changes.
- Walk your engineers through the token migration options and the conditions that would trigger that work.
- Provide runbooks for rotating credentials and reviewing access after upgrades or identity changes.
How we support
- Ongoing support, upgrades and repeat security testing are available as a retainer after handover.
- Retainer work can re-run the REST access test suite when Flowable, Spring or your identity provider changes.
- Support covers reviewing new endpoints or integrations before they are exposed to callers.
- Ask any partner, including DeployOpen, to confirm in writing which environments and versions a support agreement covers.
