Sometimes it can take time to see the beauty in things. But there are moments in life when you suddenly see it so clearly in front of you — the beautiful header, the mysterious body, a wonderful product of humankind! I'm talking, of course, about JWT Secured Authorization Response Mode (JARM).

Works Like a JARM

JWT Secured Authorization Response Mode allows you to simultaneously use signed and encrypted responses. But why introduce another encryption if there is TLS to protect the communication?

Well, JARM and TLS operate on different layers. TLS terminates eventually. If not in a gateway, then in the browser. Vulnerabilities in the application enable an attacker to intercept OAuth or OpenID Connect flows despite TLS. Consequently, additional measures for the OAuth and OpenID Connect protocols are required to mitigate this risk.

Signed and encrypted requests for OAuth (JAR) and OpenID Connect (Core) are examples of such measures. The Authorization Server can verify that a signed request was sent by the claimed client and that it has not been tampered with. This protects the integrity of the request.

To forge a request, an attacker must obtain the client's key. When encrypting requests, some or all request parameters are protected against unintended disclosure to the end-user, the browser, or any attacker on the way. This protects the confidentiality of the request.

While these specifications ensure that the server does not respond to illegitimate requests, an attacker may still target the server's response.

JARM Offensive

A client should also be able to validate a response. It should have the tools to verify that a response matches a specific request and comes from the expected server. If not protected, a response could be intercepted or crafted in a way so that the client gets tricked into sending an Authorization Code or Access Token to a server under an attacker's control. JARM protects against so-called mix-up attacks.

A mix-up attack can occur when a client integrates with several Authorization Servers, one of which misbehaves. In this attack, a client is instructed to initialize a login at a server (1) under the control of an attacker (Attacker AS). The attacker's server responds with a redirect (4) to an "honest Authorization Server" (Honest AS). Upon successful user authentication (6), the honest Authorization Server returns an Authorization Code or Access Token (7). The client remembers that the login started at the attacker's Authorization Server and redeems the Authorization Code from the attacker's server (9). The attacker can now get hold of a valid Access Token from the honest server (10,11).

This attack works because the client cannot verify that a given Authorization Code belongs to a specific Authorization Server. It cannot verify that the response (7, 8) originates from a particular Authorization Server. If the response contained an identifier of the issuer of the Authorization Code or Access Token, such as the iss parameter, the client would be able to detect callbacks from unexpected origins in the flow.

Turn on the JARM

A JWT Secured Authorization Response contains the issuer of the response and even more details. That's why JARM also protects against replay attacks and credential leakage — all in one single mechanism. That's awesome! Convince yourself and read up on JARM.