Why Signed Authorization Requests Elevate Your Security
Signed authorization requests enhance the security of authentication flows and can be implemented as JWT-secured Authorization Requests (JARs). In this blog post, we’ll explore what JARs are and how they protect from common attack vectors. This focus on JARs stems from recent industry developments and particularly the new requirements for Finnish Trust Network (FTN) logins.
FTN Security Requirements: What You Need to Know
The Finnish government is introducing new requirements to tighten authentication security of the Finnish Trust Network (FTN). The requirements are described in Recommendation 213/2023 S Finnish Trust Network OpenID Connect Profile and include:
- Private Key JWT client authentication
- Authentication request signing
- Encrypted token and userinfo responses
We've just implemented these changes at Criipto and are sharing the details with you in this article series. The goal is to explain the main concepts and demonstrate how these requirements enhance the overall security of authentication flows.
If you're integrating with FTN, you have to understand and implement these changes. Even if FTN is not among the eIDs you currently use, we encourage you to familiarize yourself with these concepts: similar security measures might be adopted by other eIDs in the future, or you might simply gain a better understanding of modern authentication security.
This blog post covers authentication request signing, which is implemented through JARs.
Note: We use the terms "authorize requests," "authorization requests," and "OIDC authentication requests" interchangeably throughout this blog post. Technically, an OIDC Authentication Request is an OAuth 2.0 Authorization Request that requires end-user authentication and requests user identity information from the authorization server.
The standard OAuth authorization request
Let’s first look at the basic authorization request.
If you’re familiar with OAuth 2.0 and OpenID Connect, you know that the client application must send an authorization request to the authorization server to initiate the user authentication flow. The user’s browser is redirected to the authorization server with a URL like this:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc
Here, parameters like client_id, response_type, scope, and state are sent directly in the URL query string.
The problem with traditional authorization requests
While convenient and simple, standard authorization requests have several inherent issues that may undermine their security:
1. Risk of tampering
When your client application redirects a user's browser to the authorization server, the authorization URL and its parameters are transmitted openly and can be intercepted. A malicious actor could alter these parameters before the request reaches the authorization server.
Request tampering can lead to serious issues, such as redirecting the user to a malicious site after authentication (though redirection is almost always protected) or changing the requested permissions. It's especially dangerous if an attacker can alter the scope and code_challenge parameters. Modifying the scope parameter could compromise a greater volume of personal data, while changing the code_challenge for a public client essentially removes any protection during the code-for-token exchange.
2. Uncertain origins
A standard authorization request initiated by your client application is sent to the authorization server by the user's browser. There's no inherent cryptographic guarantee that the request originated from your application.
Once basic details like your application’s client ID and redirect URI are known, anyone can create an authorization request. This makes it difficult for the authorization server to distinguish between a legitimate request and an unauthorized party trying to impersonate your application.
3. No guarantee of confidentiality
Even though the communication channel is typically secured with HTTPS, the parameters of the authorization request are still visible and accessible to various intermediaries. These include proxies, load balancers, or even browser extensions. As a result, a malicious network component could read, inject, or modify request parameters.
What are JARs?
A JWT-secured Authorization Request (JAR) is a method, defined by RFC 9101, where the authorization request parameters are encapsulated in a JSON Web Token (JWT) signed by your application’s private key and included in the authorize request via the request parameter.
Essentially, a standard authorize request structured like this:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc
is transformed as follows:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&request=eyJhbGciOiJSUzI1NiIsImtpZCI6InlhcmxzZXYifQ.eyJpc3MiOiJ5b3VyX2NsaWVudF9pZCI...
where the request parameter contains the Request Object: the JWT whose claims hold the JSON-encoded authorization request parameters.
The advantages of signed authorization requests
Signed authorization requests strengthen the security of the authorization flow and the resulting user authentication. The benefits include:
1. Integrity protection
Including the entire set of authorization parameters in a signed JWT lets the authorization server cryptographically verify that the request has not been altered after it was signed by your client application. Any tampering would invalidate the signature, and the request would be rejected.
2. Source authentication and non-repudiation
The digital signature on the Request Object acts as proof of origin. Only your client application, controlling the private key of the public-private key pair, can generate a valid signature. This ensures that the authorization server can trust the source of the authentication request. Your client cannot later deny having sent it, as the signature serves as cryptographic evidence of its origin and provides stronger non-repudiation.
3. Data collection minimization
Online services may request more personal data than strictly necessary, and users often can’t verify the legitimacy of data requests. To address this, JARs can be signed by a trusted third party who attests that the authorization request complies with a specific policy (e.g., confirming all requested personal data is strictly necessary for the user's intended process). The authorization server can then examine this signature and display its conformance status to the user, if necessary. This assures the request's legitimacy, helps limit data collection, and ultimately contributes to building end-users’ trust.
In summary
The Finnish Trust Network's new requirement for signed authentication requests is a step toward building a more secure digital identity ecosystem.
By embracing this standard, service providers and client applications can ensure the integrity and authenticity of their authentication requests, protecting both their users and their services from common attack vectors.
While it introduces an additional layer of cryptographic complexity, the security benefits far outweigh the implementation effort.
