Keycloak Pushed Authorization Request
You set up a keycloak pushed authorization request by sending login details through a direct server call. The identity server returns a short reference string that the browser uses to log in. Most teams turn on this rule for high-risk apps that need strict identity checks. Still, once a user logs in, broad database or server roles still grant full control. How a keycloak pushed authorization request works Standard login flows pass request details inside the browser address bar. A user or a br
Keycloak + Pushed Authorization Requests (PAR): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak pushed authorization request by sending login details through a direct server call. The identity server returns a short reference string that the browser uses to log in. Most teams turn on this rule for high-risk apps that need strict identity checks. Still, once a user logs in, broad database or server roles still grant full control.
How a keycloak pushed authorization request works
Standard login flows pass request details inside the browser address bar. A user or a browser extension can read or change those details in transit. Long request strings can also break when they hit browser length limits. Pushed authorization fixes this by moving the first step off the browser.
First, your app talks straight to the identity server over a private network path. The app proves its own identity with a secret key or a signed certificate. At the same time, the app sends the scope, redirect path, and login rules. The identity server checks these details and stores them in memory for a short time.
Next, the identity server sends a single reference string back to the app. The app redirects the user and their browser to the login page with that string. The browser never holds the raw scopes or custom claims in the address bar. The identity server looks up the stored rules using the reference string and finishes the login.
Setting up client policies for back-channel requests
You can allow or force this flow inside your realm and client settings. Most teams start by enabling pushed requests on one test app first. You give the client a strong credential so it can call the back-channel endpoint. Public apps that run only in a browser cannot keep a secret safe.
Once the app works, you can enforce pushed requests through realm client policies. A policy profile tells the server to reject any normal login link from the browser. If an app tries to send raw parameters in the address bar, the login fails. You should also keep the lifetime of the reference string very short. A short timer stops attackers from reusing old login links.
Teams also pair this setup with signed request objects for extra safety. Signed objects prove that no system changed the payload before it reached the server. This combination meets strict banking and financial security standards for user login.
Keycloak + Pushed Authorization Requests (PAR): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login rules solve and what they leave open
Pushed requests solve a real problem during the initial login step. They stop users from tampering with scopes or reading hidden claims in the browser. They also keep long login payloads from failing on older web browsers. Your identity server knows for sure which app started the login flow.
Still, this protection stops the moment the identity server issues a token. Login rules only decide who can enter an app or open a tool. They do not watch or control what the user does after logging in. A developer who logs into a database tool still gets a full session.
Inside that session, the identity server cannot see individual SQL queries or shell commands. If a role allows read rights on a table, the user can pull every row by default. The login server cannot rewrite emails, phone numbers, or card numbers in query results. It also cannot ask a team lead to approve one risky delete command in flight. To control real actions, teams need runtime checks at the command and query level.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why use pushed authorization instead of standard OAuth redirects?
Standard redirects expose scopes and parameters in the browser address bar where users can edit them. Pushed requests send those details server-to-server first so nobody can read or change them.
Can public browser apps use pushed authorization requests?
Pushed requests work best with confidential apps that hold a server secret or certificate. Pure browser apps cannot hide a secret, so they cannot prove their identity on a back channel.
Does a pushed authorization request restrict database queries after login?
No, it only secures the initial login handshake between the app and the identity server. Once the user gets a token, the identity server does not inspect queries or commands.