Revoke application artifacts through administration flows

Deleting an application or rotating its client secret are security events:
artifacts already issued to that application's OAuth client must stop being
accepted. Carry both out through administration flows so the revocation, the
session detachment and the action itself run as one orchestrated sequence.

Resolve an artifact's lifetime through an injected collaborator rather than by reading
the server runtime. Sizing a revocation needs the longest an artifact issued to a client
can live, which is a fact about OAuth token configuration, so the computation belongs to
tokenservice and the application declares only the resolver it calls. The composition
root is the one place that sees both domains, so it supplies it: the application package
carries no OAuth configuration dependency and reads no global state.

One preparatory executor serves both flows, selected by the node's revocation mode.
The mode states the breadth of the revocation, and each breadth belongs to exactly one
action: a deletion retires the client id, so every artifact it ever carried is denied,
while a secret regeneration denies only what was issued before the rotation. It
declares no default mode, so flow creation requires a node to state one.

Add two shipped ADMINISTRATION flows, default-application-deletion-flow and
default-client-secret-regeneration-flow, built from four new executors. The
preparatory node validates the target and publishes a trusted revocation plan;
the criteria and session nodes act on that plan; the final node performs the
delete or the rotation. Deletion revokes terminally, since a retired client id
can carry no future artifact. Rotation revokes only up to a cutoff, so tokens
minted with the new secret still pass.

Name both flows in the flow server-config section, alongside userDeletionFlow,
and drive them from the console: the delete action and the regenerate-secret
action resolve their configured handle and execute the flow, falling back to the
native endpoint only when no such flow is configured. The rotation flow returns
the new secret, generated with the server's entropy rather than the browser's,
in the only response that exposes it.

The native application endpoints are left unchanged, so revocation has exactly
one home.

A refused step reports its executor error in the response's error envelope, not
in a failureReason field that the API never sends. Read the real envelope and
carry the code on the thrown error so the console shows why a flow refused
instead of a generic failure, and apply the same fix to the user deletion path.

Cover the detachment in the integration suite. Deleting an application through
the flow was only ever exercised against an application nobody had logged into,
so the session node returned on an empty participation list and the work it
exists to do never ran. Two tests now establish a real session: one where a
second application shares it, which must survive the deletion, and one where the
deleted application was its only participant, which must not. Rotation refusals
for an application with no OAuth component, for a public client and for an
unknown application are covered alongside them.

Keep the seam internal. The administration executors declare the application
contract they consume in the executor package, so the flow's dependency on the
application service adds nothing to pkg, where anything added is exported from the
library and cannot be changed without a major release.

Name the credential operations for the credential rather than for the one action
they perform today, and report what validation found rather than what a revocation
needs. Validation answers whether an action may proceed and describes the artifacts
the application has issued; sizing a deny-list row from that description is one
consumer's business, not validation's. Further credential actions, a rotation that
keeps the old secret briefly valid and additional secrets, arrive as actions on the
same pair of methods instead of methods of their own.

Refuse the deletion while a dependent forbids it, the check userService already
performs before a user is deleted. The cascade removes the dependents that cascade;
this refuses the ones that must not go silently, and fails closed when a provider
cannot report its usage, since deleting on an unknown answer is what the check exists
to prevent.

Cover the branches an integration test can reach: the declarative refusal on both
administration flows, a target that is not an application, and the client-credentials
and refresh-token validity paths that decide how long a deny-list row must outlive the
artifacts it denies.

What remains uncovered in the application and session packages is error handling the
integration suite has no way to provoke: a failing dependency lookup, a corrupt
attribute blob, a failing client-secret write, a failing participation query, a failing
token-family revocation, a failing transaction. Reaching those needs fault injection,
which lives in the unit suite, and the integration patch-coverage check deliberately
does not load unit coverage. No threshold entry is recorded for them, so that check
reports both packages below its bar.

Size the deny-list row from both access-token subject configurations. Access token
validity is configured per token subject, and client_credentials reads the client
sub-config while the row was sized from the user one alone. A machine-to-machine
application with a longer client-token validity therefore got a row that went inert
while the tokens it denies were still valid, which is the failure this sizing exists
to avoid.

Carry the validator's own refusal out of the preparatory node. Every client-side
refusal became the executor's single error, so an application owned by a declarative
file, and one that no longer exists, were both reported as having no client secret to
rotate. The console resolves these codes to messages, so the reason it showed was
wrong rather than merely vague.

Refuse rather than fall back when a configured administration flow cannot be resolved.
An unset handle is the documented opt-out and still falls back to the native endpoint.
A handle that names a missing flow is the opposite: the deployment asked for flow-based
revocation, and deleting or rotating natively would strip the application or mint a new
secret while leaving every issued artifact valid, and report it as a success.

Name the secret executor for the artifact it acts on rather than the one action it
performs today. An executor name is persisted into stored flow definitions and their
version history, so a deployment that authors a flow against
ClientSecretRegenerationExecutor pins that name, and renaming it once further secret
actions exist would break those flows and need a migration. ClientSecretExecutor
carries the same behaviour under a name that already fits the rotation and additional
secrets that arrive later as executor modes.

Signed-off-by: Indeewai Wijesiri <indeewari@wso2.com>

Author: indeewari

backend/.mockery.public.yml

@@ -404,13 +404,16 @@ packages:
       pkgname: flowmgtmock
       filename: "{{.InterfaceName}}_mock.go"
 
+  # Only the registry is mocked outside this package. The rest of the executor interfaces are internal
+  # seams, and one of them names an unexported type, which a mock in another package cannot reference.
   github.com/thunder-id/thunderid/internal/flow/executor:
     config:
-      all: true
       dir: tests/mocks/flow/executormock
       structname: '{{.InterfaceName}}Mock'
       pkgname: executormock
       filename: "{{.InterfaceName}}_mock.go"
+    interfaces:
+      ExecutorRegistryInterface:
 
   github.com/thunder-id/thunderid/internal/flow/interceptor:
     config:

backend/cmd/server/bootstrap/01-default-resources.yaml

@@ -1991,6 +1991,168 @@ nodes:
       x: 1740
       y: 200
 ---
+resource_type: flow
+id: 01900000-0000-7000-8000-000000000079
+name: Default Application Deletion Flow
+handle: default-application-deletion-flow
+flowType: ADMINISTRATION
+nodes:
+- id: start
+  type: START
+  onSuccess: permission_validator
+  layout:
+    size:
+      width: 101
+      height: 34
+    position:
+      x: 100
+      y: 200
+- id: permission_validator
+  type: TASK_EXECUTION
+  executor:
+    name: PermissionValidator
+  onSuccess: validate_application_deletion
+  layout:
+    size:
+      width: 206
+      height: 113
+    position:
+      x: 300
+      y: 175
+- id: validate_application_deletion
+  type: TASK_EXECUTION
+  executor:
+    name: ApplicationActionValidator
+    mode: revoke_all
+  onSuccess: revoke_tokens
+  layout:
+    size:
+      width: 240
+      height: 113
+    position:
+      x: 580
+      y: 175
+- id: revoke_tokens
+  type: TASK_EXECUTION
+  executor:
+    name: CriteriaRevocationExecutor
+  onSuccess: revoke_sessions
+  layout:
+    size:
+      width: 206
+      height: 113
+    position:
+      x: 900
+      y: 175
+- id: revoke_sessions
+  type: TASK_EXECUTION
+  executor:
+    name: SessionRevocationExecutor
+  onSuccess: delete_application
+  layout:
+    size:
+      width: 206
+      height: 113
+    position:
+      x: 1180
+      y: 175
+- id: delete_application
+  type: TASK_EXECUTION
+  executor:
+    name: ApplicationDeleteExecutor
+  onSuccess: end
+  layout:
+    size:
+      width: 220
+      height: 113
+    position:
+      x: 1460
+      y: 175
+- id: end
+  type: END
+  layout:
+    size:
+      width: 85
+      height: 34
+    position:
+      x: 1760
+      y: 200
+---
+resource_type: flow
+id: 01900000-0000-7000-8000-00000000007a
+name: Default Secret Regeneration Flow
+handle: default-secret-regeneration-flow
+flowType: ADMINISTRATION
+nodes:
+- id: start
+  type: START
+  onSuccess: permission_validator
+  layout:
+    size:
+      width: 101
+      height: 34
+    position:
+      x: 100
+      y: 200
+- id: permission_validator
+  type: TASK_EXECUTION
+  executor:
+    name: PermissionValidator
+  onSuccess: validate_secret_regeneration
+  layout:
+    size:
+      width: 206
+      height: 113
+    position:
+      x: 300
+      y: 175
+- id: validate_secret_regeneration
+  type: TASK_EXECUTION
+  executor:
+    name: ApplicationActionValidator
+    mode: revoke_before_action
+  onSuccess: revoke_tokens
+  layout:
+    size:
+      width: 250
+      height: 113
+    position:
+      x: 580
+      y: 175
+- id: revoke_tokens
+  type: TASK_EXECUTION
+  executor:
+    name: CriteriaRevocationExecutor
+  onSuccess: regenerate_secret
+  layout:
+    size:
+      width: 206
+      height: 113
+    position:
+      x: 920
+      y: 175
+- id: regenerate_secret
+  type: TASK_EXECUTION
+  executor:
+    name: ClientSecretExecutor
+  onSuccess: end
+  layout:
+    size:
+      width: 250
+      height: 113
+    position:
+      x: 1200
+      y: 175
+- id: end
+  type: END
+  layout:
+    size:
+      width: 85
+      height: 34
+    position:
+      x: 1520
+      y: 200
+---
 resource_type: theme
 id: 01900000-0000-7000-8000-000000000071
 handle: acrylic-orange

backend/cmd/server/bootstrap/02-server-configurations.yaml

@@ -16,3 +16,7 @@ value:
     expirySeconds: 86400
   userDeletionFlow:
     defaultHandle: default-user-deletion-flow
+  applicationDeletionFlow:
+    defaultHandle: default-application-deletion-flow
+  secretRegenerationFlow:
+    defaultHandle: default-secret-regeneration-flow

backend/cmd/server/servicemanager.go

@@ -64,6 +64,7 @@ import (
 	"github.com/thunder-id/thunderid/internal/oauth/oauth2/dpop"
 	"github.com/thunder-id/thunderid/internal/oauth/oauth2/jti"
 	"github.com/thunder-id/thunderid/internal/oauth/oauth2/revocation"
+	"github.com/thunder-id/thunderid/internal/oauth/oauth2/tokenservice"
 	"github.com/thunder-id/thunderid/internal/openid4vci"
 	"github.com/thunder-id/thunderid/internal/ou"
 	"github.com/thunder-id/thunderid/internal/resource"
@@ -417,8 +418,14 @@ func registerServices(mux *http.ServeMux, cacheManager cache.CacheManagerInterfa
 
 	applicationService, applicationExporter, err := application.Initialize(
 		mux, mcpServer, entityService, inboundClientService, ouService, i18nService,
-		runtimeCryptoSvc, serverConfigService)
+		runtimeCryptoSvc, serverConfigService,
+		func(client *providers.OAuthClient) time.Duration {
+			return tokenservice.ArtifactLifetime(oauthCfg, client)
+		})
 	fatalOnError(ctx, logger, err, "Failed to initialize ApplicationService")
+	// Two-phase initialization: inject the application service into the executors that act on it.
+	fatalOnError(ctx, logger, executor.SetApplicationProvider(execRegistry, applicationService),
+		"Failed to inject the application provider into the flow executors")
 	exporters = append(exporters, applicationExporter)
 
 	agentService, agentExporter, err := agent.Initialize(mux, entityService, inboundClientService, ouService,

backend/dbscripts/runtime_persistent/postgres.sql

@@ -95,6 +95,10 @@ CREATE TABLE "SSO_SESSION_PARTICIPANT" (
     PRIMARY KEY (SESSION_ID, DEPLOYMENT_ID, APP_ID)
 );
 
+-- Index for participation lookups by application, used when an application is deleted and its
+-- participation must be detached from every session it joined.
+CREATE INDEX idx_sso_session_participant_app ON "SSO_SESSION_PARTICIPANT" (DEPLOYMENT_ID, APP_ID);
+
 -- Table to store consent records.
 CREATE TABLE "CONSENT" (
     DEPLOYMENT_ID VARCHAR(255) NOT NULL,

backend/dbscripts/runtime_persistent/sqlite.sql

@@ -95,6 +95,10 @@ CREATE TABLE "SSO_SESSION_PARTICIPANT" (
     PRIMARY KEY (SESSION_ID, DEPLOYMENT_ID, APP_ID)
 );
 
+-- Index for participation lookups by application, used when an application is deleted and its
+-- participation must be detached from every session it joined.
+CREATE INDEX idx_sso_session_participant_app ON "SSO_SESSION_PARTICIPANT" (DEPLOYMENT_ID, APP_ID);
+
 -- Table to store consent records.
 CREATE TABLE "CONSENT" (
     DEPLOYMENT_ID VARCHAR(255) NOT NULL,