Local JWT vs External OAuth2: Balancing Simplicity and Revocation Control

The direct answer

For a single‑operator or small‑team Gazebo web interface, a local JWT scheme with short‑lived access tokens plus a small server‑side denylist is usually the right balance. Move to an external OAuth2/OIDC provider only when you genuinely need SSO, multiple users with audit trails, or immediate revocation guarantees. And enforce least‑privilege roles in the web backend via token claims — ROS 2 Security (DDS‑Security) is orthogonal and does not replace it.

Why expiry‑only JWTs have a revocation gap

A JWT is self‑contained: once issued, any validator that checks the signature and exp claim will accept it until it expires. There is no callback to the issuer. That means a leaked or logged‑out token stays valid for its full lifetime. Your options to close the gap, in increasing order of complexity:

1. Short expiry only. Issue tokens valid for minutes, not hours. Zero extra state, but logout is not instant.
2. Denylist. Store revoked token IDs (jti claims) in a fast cache (e.g., Redis) with TTLs matching token expiry, and check it per request. This reintroduces a little server‑side state but is far simpler than OAuth2.
3. Refresh tokens. Short‑lived access tokens plus server‑stored refresh tokens give you a natural revocation point: delete the refresh token and the session dies within one access‑token lifetime.

What OAuth2 actually buys you

An external provider (Keycloak, Auth0, etc.) offers centralized credential management, SSO, and revocation via token introspection (RFC 7662). Two caveats matter for your decision:

• OAuth2 access tokens are frequently JWTs too. If you validate them locally by signature alone, you have the same revocation gap. The benefit only materializes if you call the introspection endpoint per request (adding latency and a hard dependency on provider availability) or use short expiry with refresh‑token rotation.
• Your web UI’s availability becomes coupled to the provider. For a robot interface that must work on an isolated field network, that coupling can be a real operational risk.

Does Gazebo revoke JWTs natively?

There is no widely documented built‑in JWT revocation endpoint in Gazebo’s web tooling, so the safe assumption is that you must add one yourself (denylist or refresh‑token store). However, Gazebo Classic and the newer Gazebo Sim (formerly Ignition) differ substantially, and web components vary by release — before committing, inspect the changelog and web‑server source for your exact version, and test empirically: issue a token, attempt to invalidate it, and confirm whether requests are rejected before exp.

Where least‑privilege belongs

Enforce roles at the JWT/application layer: put role or scope claims in the token and have the web backend check them on every endpoint. ROS 2 Security (SROS2/DDS‑Security) authenticates DDS participants and governs topic‑level permissions inside the robot middleware — it knows nothing about browser users. The two layers complement each other: the web backend, acting as a DDS participant, should itself run under least‑privilege DDS permissions, but user authorization stays in the web tier regardless of whether you use local JWTs or OAuth2.

Practical checklist

• Set access‑token TTL to 5–15 minutes; allow small clock‑skew tolerance when checking exp.
• Always include a unique jti so tokens are individually revocable.
• If evaluating OAuth2, prototype with Keycloak in a container and measure introspection latency versus local validation.
• Document why you chose the simpler design if multi‑user SSO isn’t needed — it saves re‑legitimating the decision later.