Runtime Authorization
Purpose
This functional area decides whether a caller is allowed to invoke a tool.
Main Capabilities
- default-deny enforcement
- policy evaluation per tool
- tenant-aware authorization
- claim-based access matching
- browser-based operator approval for runtime OAuth authorization requests
- alignment between runtime browser authorization and the operator's current Portal session context
- immediate rejection of tokens whose underlying session has been revoked
Supported Policy Dimensions
- issuer
- client ID
- roles
- scopes
- groups
- custom claim requirements
Browser Authorization Flow
For browser-capable runtime clients, authorization is mediated through the Portal login experience.
Functionally this means:
- the runtime authorization request is redirected into Portal.Web with the original OAuth parameters preserved
- operators can complete the same sign-in requirements they would for any normal portal session, including external provider authentication and MFA
- after authentication, the Portal presents a dedicated authorization review step instead of silently completing the request
- the operator must explicitly confirm that the requesting application should receive runtime access through the current portal account
- the resulting authorization code inherits the same tenant scope and effective permissions as the authenticated portal session that approved it
This keeps runtime browser authorization consistent with the platform's human sign-in and consent controls instead of maintaining a separate reduced-capability login surface.
Session Revocation Enforcement
Access tokens presented to the Runtime are checked against session revocation state on every request, not just at issuance time.
Functionally this means:
- when an operator or administrator revokes a session in the Portal, any access token already issued from that session stops working the next time it is presented to the Runtime — the caller does not need to wait for the token's own expiry
- this applies uniformly regardless of how the token was obtained: local sign-in, external identity provider sign-in, the device authorization flow, or the runtime OAuth authorization-code flow
- if the platform detects signs of refresh-token theft (a stale or already-used token being replayed) and automatically revokes every active session for that account as a precaution, all of those sessions' tokens are rejected by the Runtime immediately, not just the one that triggered the detection
- revocation is enforced consistently whether the token is presented to the Runtime or back to the Portal itself
This closes a gap where a session that had been explicitly revoked, or automatically revoked in response to suspected token theft, could still be used to invoke tools against the Runtime until its access token expired on its own.
Functional Value
This area ensures the Runtime is not just discoverable, but governed at the point of use.