Auth, RAR, and PAR — The Building Blocks of Modern OAuth

🧭 Taking a Step Back

In the past few years, the world of authentication and authorization has evolved quickly.
It’s no longer just about getting an access token, it’s about expressing intent, ensuring security, and making user consent meaningful.

Three concepts are central to this shift:
Auth, RAR, and PAR.

Let’s take a step back and unpack what they mean, and why they matter.

🔐 Authentication — Who are you?

Every secure interaction starts with identity.
Authentication is the moment the system says: “I know who you are.”

When you log into an app with your Google or Apple ID, that’s authentication.
You prove who you are — often via password, biometrics, or passkeys — and receive an ID token (usually a JWT) confirming your identity.

That’s the foundation.
But modern apps need more than just identity. They need context.

🧾 RAR — What exactly do you want to do?

In traditional OAuth flows, apps request access using broad scopes:

scope=read write email

That’s okay for simple cases.
But what if your app needs to initiate a payment, share a document, or access a medical record under precise conditions?

That’s where RAR (Rich Authorization Requests) comes in.
RAR allows an app to describe its intent in structured JSON, much richer and safer than generic scopes.

Example:

{
  "authorization_details": [
    {
      "type": "payment_initiation",
      "instructedAmount": {
        "currency": "EUR",
        "amount": "125.00"
      },
      "creditorName": "Green Energy Ltd."
    }
  ]
}

Now the Authorization Server knows exactly what’s being asked and the user can give consent with full clarity.

👉 Instead of “the app can do something,” we’re saying “the app can make this specific payment.”

🚀 PAR — How do we send this request safely?

RAR gives us expressiveness, but it also makes the authorization request heavier.
Traditionally, the app would pass everything through the browser in a long query string:

https://auth.example.com/authorize?client_id=123&scope=read write

Not ideal.
Those URLs can leak through logs, analytics, browser history, and even referrers.

That’s why PAR (Pushed Authorization Requests) was created.
It allows the app to push the authorization request directly to the Authorization Server via a secure backchannel:

POST /par
client_id=123
request=eyJhbGciOi...

The server responds with:

{ "request_uri": "urn:par:xyz123", "expires_in": 90 }

And the app then redirects the user using only that short request_uri.

It’s cleaner, safer, and easier to monitor.

🔁 Putting It All Together

Here’s the bigger picture:

sequenceDiagram
    participant App
    participant AuthServer
    participant User

    App->>AuthServer: POST /par (Auth + RAR payload)
    AuthServer-->>App: request_uri = urn:par:abc123
    App->>User: Redirect to /authorize?request_uri=urn:par:abc123
    User->>AuthServer: Logs in (Authentication)
    AuthServer-->>App: Authorization Code
    App->>AuthServer: Exchange Code for Tokens
    AuthServer-->>App: Access + ID Token

• Auth ensures the user is who they claim to be.
• RAR defines what the app wants to do in detail.
• PAR ensures that request is sent securely.

Together, they make OAuth2 more robust, auditable, and user-friendly, exactly what modern systems need.

🧩 A Real-World Example

Imagine a banking app initiating a SEPA payment.
Instead of a vague “payment” permission, the app sends a RAR object describing the transaction (amount, recipient, currency).
Then it pushes that request securely via PAR.
When the user logs in, they see the exact details and can approve or reject it.

No ambiguity. No leakage. No confusion.

⚙️ In Summary

These standards might sound abstract, but they’re becoming foundational, especially in sectors like finance (PSD2, open banking) and healthcare.
They help bridge the gap between security and user trust, two things that used to pull in opposite directions.

If you’re building or integrating modern APIs, take time to understand RAR and PAR.
They’re not just acronyms, they’re the next step in making OAuth both safer and more human.