Lakhan Samani

Also, may I know which version of Authorizer you are running at the moment? And which deployment method are you using [docker, k8s, railway, etc...]?

Thanks for reading and appreciating it. On your migration question. The OAuth 2.1 work is mostly opt-in, but not entirely. --oauth2-1-strict defaults to false. Turn it on and /authorize rejects response_type=token and id_token token, and PKCE plain gives way to S256. Leave it off and those flows behave as they do in 2.3. Discovery still advertises implicit and plain while it's off, because the endpoint still accepts them. What isn't behind the flag: refresh-token reuse detection. Replaying an already-rotated refresh token now revokes that token's family. It's scoped to the lineage rather than the user, so other sessions and login methods stay alive, and there's a grace window for benign double-submits, so a SPA firing two concurrent refreshes won't get logged out. The resource → aud binding is also always on, but only fires if a client sends resource, which existing clients won't. Treat both new flags as required setup. --url is enforced: the server exits without it. It closes header-derived host takeover, where the server took its own identity from request headers and an attacker could get a genuine password-reset link pointed at a domain they control. Set --encryption-key in the same change. It keys secrets at rest: TOTP seeds, and the OTP digests behind email/SMS verification and password reset. Pick a strong random value and then leave it alone. There's no re-encryption path, so changing it later means every enrolled TOTP user has to re-enroll.

Hey thank you, Pls check the demo (https://youtu.be/X0RA-sP8Z5I) + examples (https://github.com/authorizerdev/examples/tree/main/with-agent-permissions) Can get in touch if you would like to have it configured.