Loopback Interface Redirection

4 min readJan 5, 2022

Introduction

This article is about “Loopback Interface Redirection” which is written in the Section 7.3. Loopback Interface Redirection of RFC 8252 OAuth 2.0 for Native Apps.

Specification

The specification requires an authorization server to treat the port number component of redirection URIs as variable when the host component is a loopback IP address.

The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.

To be concrete, when the host component of a redirection URI which is included in an authorization request is either 127.0.0.1 or ::1 (or equivalent), the authorization server must ignore the port number component when comparing the specified redirection URI to pre-registered ones.

For example, if an authorization request includes redirect_uri=http://127.0.0.1:12345/callback and the client application has pre-registered http://127.0.0.1/callback as a redirection URI, the authorization server must judge that the specified redirection URI matches the pre-registered one.

Conflict among Specifications

A problem is that the requirement in the Section 7.3 of RFC 8252 conflicts with the requirement in the Section 3.1.2.3. Dynamic Configuration of RFC 6749 The OAuth 2.0 Authorization Framework:

If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1.

and the requirement in the Section 3.1.2.1. Authentication Request of OpenID Connect Core 1.0:

redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). (The rest is omitted.)

Both the requirements explicitly require “Simple String Comparison” which does not allow the port number component to be variable.

Conflict Resolution

Considering the historical background, it is natural to think that the requirement in RFC 8252 takes precedence over the requirements in RFC 6749 and OpenID Connect Core 1.0.

But, it should be noted that the Section 7.5. Native Apps of Financial-grade API 1.0 Baseline mentions BCP 212, which was the base of RFC 8252, and prohibits authorization servers from supporting Loopback Interface Redirection:

When registering redirect URIs, authorization servers
1. shall not support “Private-Use URI Scheme Redirection”; and
2. shall not support “Loopback Interface Redirection”.

Therefore, the behavior described in the Section 7.3 of RFC 8252 must not be supported in the FAPI context.

Implementation

Scheme Component

The Section 7.3. Loopback Interface Redirection and the Section 8.3. Loopback Redirect Considerations repeatedly say “Loopback redirect URIs use the http scheme.” So, it may happen that implementers choose to treat the port number component as variable only when the scheme component is http. However, some experts in the industry said “there is no clear reason to limit it to the http scheme only.”

Therefore, the implementation of Authlete treats the port number component as variable even if the scheme component is not http.

NOTE: Authlete supports the behavior of RFC 8252 Section 7.3 from the version 2.2.22.

Localhost

The use of localhost is not recommended as the Section 8.3. Loopback Redirect Considerations of RFC 8252 says as follows:

While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.

So, implementations may choose not to treat the port number component as variable when the host component is localhost.

However, the implementation of Authlete treats the port number component as variable when the host component is localhost for the following reasons.

The implementation of Active Directory treats the port number component as variable in the case of localhost (Localhost exceptions), and there are actually voices requesting the same behavior.
It is perfectly controllable on the client application side whether to use localhost or not.

Configuration

To enable developers to choose the backward-compatible behavior, Authlete has prepared a flag, “Variability of loopback redirection URIs”, which turns on and off the behavior of RFC 8252 Section 7.3. The flag corresponds to the loopbackRedirectionUriVariable property of the Service class (cf. isLoopbackRedirectionUriVariable()).

As new use cases and attack methods emerge, OAuth-related specifications increase. Under such circumstances, it is not uncommon for specifications to conflict with each other, as in the case introduced in this article.

There are various conflict patterns from easily-understandable ones like “RFC 7518 recommends RS256 as a signature algorithm but Financial-grade API 1.0 Advanced prohibits it for security reasons” to unintelligible ones such as breaking changes introduced by RFC 9101 (cf. Implementer’s note about JAR (JWT-Secured Authorization Request)).

It is hard to keep pace with evolution of standard specifications and continue to update the implementation of authorization server for your service. If you would like to leave these tasks to an expert, please contact Authlete!