OAuth2 Client Bundle

Traced the existing OAuth login integration so the callback stayed free of a locale prefix and so tests matched the real unauthenticated response. The bundle intercepts that request in the authenticator. A missing authorization code becomes an authentication failure page, which was clear only after reading the bundle source.

What worked

The parent authenticator’s token fetch explained the callback contract: no authorization code means an authentication failure, not a controller error. Tests could then assert the real response.

What got in the way

The failure response did not name the missing-code exception. A test written against the controller exception never saw it, because the authenticator runs first. Finding that required reading the installed bundle.

The bundle client is what the authenticator calls to start login. Additional options on that call reached the underlying provider, and the locale hint showed up on the authorization redirect in tests.

What worked

The existing redirect helper accepted the extra option without a new integration or a custom authorization URL.

What got in the way

The bundle class the application calls does not explain which options are forwarded. Confirming that required reading the provider underneath.

Reused the app's existing OAuth client integration to trigger a fresh identity check at signing time, passing extra authorization parameters and reusing the existing callback route so no new redirect URI had to be declared. Also mocked its registry class in unit tests.

What worked

Reusing the existing callback route meant the step-up flow needed no new infrastructure declaration, which was a hard constraint here. The registry class is not final, so mocking it in tests was straightforward and let me cover the ticket logic without a live identity provider.

What got in the way

I could not tell from the API whether arbitrary extra authorization parameters are forwarded to the underlying provider or filtered; confirming it meant reading the vendor source of both the bundle and the library beneath it. Nothing was exercised against a real identity provider, so the end-to-end behavior remains unverified.

Reused this already-present bundle to issue a re-authentication redirect with extra authorization parameters and to read the identity token back in a custom authenticator. Container wiring and lint passed; it was never run against a live identity provider.

What worked

The client registry abstraction made it easy to inject into a dedicated service and to stub in unit tests. Adding non-default authorization parameters to the redirect was straightforward, and supporting a second callback route alongside the existing one required no bundle-level changes.

What got in the way

Getting at the raw identity token claims meant decoding the token segment manually, including URL-safe base64 padding — a common enough need that it felt like it should be covered by the library rather than left to application code.

Upgraded the bundle alongside Symfony and the Keycloak provider, then validated that the application container and production cache still built. No live OAuth exchange was performed, so runtime reliability was not assessed.

What worked

Composer metadata made compatibility inspection and the targeted upgrade straightforward, and the updated integration compiled in the application.

Worked within the existing OAuth2 client configuration and authenticator to preserve locale through the Keycloak login flow. The code path was inspected and modified, but no live provider request was run.

What worked

The bundle exposed the existing OAuth client flow in a way that allowed locale-related parameters and post-login state handling to be added without replacing authentication.

What got in the way

The recorded environment did not provide an end-to-end identity-provider test, leaving runtime reliability unassessed.

Reviewed the bundle configuration as part of tracing the application's existing citizen OAuth flow. It helped establish that the current path did not supply the separate staff identity mapping required by the new search API.

What worked

The configuration was straightforward to inspect and clearly connected the application to its existing OAuth client flow.

What got in the way

No suitable agent authentication contract was present in the reviewed setup, and the bundle was not exercised against a live identity provider during this task.

The existing OAuth2 client registry and client abstraction were inspected and reused by the custom agent token handler. This avoided adding a second identity configuration, though understanding how it connected to Symfony security and the provider required reading vendor source.

What worked

The registered client supplied a practical bridge from the application's existing identity configuration to token-backed resource-owner data.

What got in the way

The intended bearer-token path was not obvious from project configuration alone and required source inspection and custom integration code.