Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect Authentication Scheme

The Hyper-Text Transport Protocol (HTTP) RFC7230 provides several schemes for user authentication. There also are popular ways of authenticating users based on redirection rather than standard HTTP authentication schemes. Heretofore, HTTP has provided no standard way for servers to know which authentication schemes, including redirect-based methods, a given user-agent supports, but servers must choose between either redirection or HTTP authentication, and these two are mutually exclusive. This situation arises especially in corporate networks where JSON Web Tokens (JWT) and Negotiate are both used, the latter usually with the Kerberos GSS-API mechanism . We address this problem by adding new request headers, "Accept-Auth:", "Accept-Redirect-Auth:", and "Accept-Redirect:" by which a user-agent can indicate which HTTP authentication schemes, if any, it supports, including redirection.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The Accept-Redirect request header has two possible values: "yes" and "no". If "yes", this means the user-agent will follow redirections, and the user-agent may or may not be willing to authenticate at the redirected origin depending on local policy. The Accept-Redirect-Auth request header exists to indicate which authorities the user-agent is willing to redirect to and authenticate at. Its value is a whitespace-separate list of domainnames. If empty or has just the value ".", then the service can conclude only that the user-agent has a whitelist, but is not disclosing it.

The Accept-Auth request header may have multiple values, or be present multiple times, as with most HTTP headers. Each value names one authentication schemes, and optionally may indicate schemes-specific metadata. Accept-Auth values are similar to WWW-Authenticate values , but they do not have quite the same form, and they are not challenges. Using ABNF :

OWS = quoted-string = ]]> Accept-Auth value ABNF.

Many sites use redirect-based protocols for authentication. Such protocols exchange cryptographic messages between a relying party origin and an authenticator origin. Some such protocols use URI query parameters to carry cryptographic messages. Others depend on the browser HTML and ECMAScript ecosystem, using a script to run HTTP requests from the authenticator to the relying party with a token in Authorization request header. In the latter case, the server exchanges the token for a cookie, and a script on the authenticator page then effects a redirect by changing the window location. Such redirect-based protocols do not work for non-browser user-agents. It might be good to also specify request headers for redirected requests that user-agents can use for passing channel binding information to auth services. E.g., Authorization-Channel-Binding: <type> <cb-data>. This would allow Authorization tokens to be channel-bound. Of course, there are difficulties here that would require additional thinking. For example, using unique CB would require that the user-agent keep a connection open to the redirecting origin. While end-point CB would fail if multiple servers serve the same origin using different server certificates for the same names. Binding to the dNSName and the issuer, however, would work, but that would be a new CB type and would require registration in the IANA CB type registry. CB support could always be added later. Possible new CB types include: dNSName+hash(issuer-cert/SPKI), some sort of TLS session ID possibly constructed using the TLS key material exporter but derived in such a way that it identifies a set of connections resumed from the same original handshake. The latter would be prone to failure on resumption if the resumption ticket is rejected for any reason, but otherwise would work really well for tokbind-style token protocols, especially for user-agents that can retry. User-agents normally do not copy response headers from redirect responses redirected requests. One common non-browser user-agent, the PowerShell command-line user-agent, has an option, -PreserveAuthorizationOnRedirect that causes it to copy Authorization headers from redirect responses to redirected requests. This enables some redirect-based workflows to work even though that user-agent is not a browser, lacks interaction capabilities, HTML rendering, or JavaScript support. Here we define the "Redirect" HTTP authentication scheme. This scheme lets arbitrary authentication (and authorization) protocols exchange cryptographic messages between the relying party origin and the authenticator origin over headers rather than URI parameters. This is done by copying ("preserving") any "Authorization" headers in a redirect response to the redirected request. For our purposes, a "redirect response" is either a 3xx redirect response with a Location header, or a 401 response with a WWW-Authenticate header naming the Redirect authentication scheme and a Location header. User-agents that support the Redirect HTTP authentication scheme MUST recognize a 401 Redirect challenge as a redirect response. QUESTION: What, if anything, should we say about the method used by the user-agent when chasing a redirection? One possibility is to let the redirecting origin specify the method and state some constraints (e.g., if the original method cannot have a request body, then the next method must be GET, else ???). Since the intent is to authenticate the user, a GET should always be good enough. In particular, the authenticator origin may not need to see the original request body at all, though it may need to know the original method, and it can get that from the relying party (e.g., via the Redirect header preservation mechanism). User-agents SHOULD also consider challenges for other authentication schemes offered by the server. E.g., if the server offers a Negotiate challenge and a Redirect challenge, the user-agent may choose either (or neither) of the two. Unless rejected by local policy (or the user), user-agents that support the Redirect HTTP authentication scheme MUST copy any Authorization headers in redirect responses to the redirected request. Servers needing to authenticate the user when the user-agent has advertised support for the Redirect authentication scheme SHOULD respond with a 401 with a "challenge" for the Redirect authentication scheme and a Location header, and MAY include an Authorization header in the response that the user-agent then MUST copy to the redirected request if it chooses to follow the redirection. Servers MAY use a 3xx response instead. Servers that have been redirected to MUST apply local policy to decide: whether to accept redirections from the redirecting origin (identified by the Referer header or by a cryptographic token in the preserved Authorization header); whether to further redirect the request (as usual) and whether to set an Authorization header in the redirect response; whether to authenticate the user (as usual); whether to redirect back to the redirecting origin, and whether to set an Authorization header in the redirect response. User-agents may consult the user (if interactive), and/or a local policy (e.g., a white-list of acceptable origins for redirections), in order to decide whether to follow the redirection. Note that the redirected-to service should always have enough information to decide whether to accept or reject a redirection (e.g., via the Referer header), and MUST have and apply local policy of its own. Note that nothing in this document alters or obviates Cross-Origin Resource Sharing policy and considerations.

Consider a URL https://janedoe.catvidhub.com.example/v0.mpg which permanently redirects to https://janedoe.catvidhub.io.example/v0.mpg, and suppose the latter also wants to authenticate users via redirection to an authenticator at https://auth.catvidhub.nu.example/. Let us label these A, B, and C respectively. The first redirection in this example is not involved in authentication, and is included only to show that a redirection chain where only parts of it are involved in authentication is possible. In this example we should see a normal redirect from A to B, and at B we should see a redirect to C, and then finally a redirect back from C to B, and then B should serve the desired resource ("/v0.mpg") if C provided the user-agent with a suitable token. Using the Redirect auth scheme we should see: Server A would respond with a normal 3xx redirect to B, not a 401 authenticate-with-Redirect, and no Authorization headers in the redirect response. Server B would respond with a 401 authenticate-with-Redirect response and (possibly) a Authorization header in the response by which it might send a signed request for authorization to the "/v0.mpg" resource. Server C would check any Authorization headers in the request and possibly authenticate the user-agent somehow (e.g., using any cookies sent by the user-agent, using client certificates in TLS, by responding with a 401 for the user-agent to authenticate using some HTTP scheme, a further Redirect or plain redirection, or by interacting with the user if the user-agent is a browser). Once the user is authenticated, server C would check the user's authorization to access the resource ("/v0.mpg"), and if permitted, would respond with a 3xx response with an Authorization header bearing a cryptographic token for B attesting to the user's authorization. Finally, on the redirect back to B, the user-agent would preserve the Authorization header from the response from C, which means server B would see it, verify its integrity, decode it, and -if the token grants access- then serve the resource.

Two different and only somewhat related features are specified here. One is intended to help interoperability in heterogeneous environments with minimal or no changes to existing HTTP implementations, just changes to applications. The other is intended to perfect existing redirect-based authentication and authorization protocols.

The purpose of the Accept-Auth , Accept-Redirect , and Accept-Redirect-Auth request headers is to improve interoperability in heterogeneous environments with minimal or no changes to HTTP implementations. For example, an application could set these request headers on requests without changes to the user-agent. That's because setting arbitrary request headers is a common feature of HTTP user-agent implementations. It is also common for HTTP server implementations to allow applications to inspect request headers produce 3xx redirect or 401 responses. Thus one can modify client applications to set these headers, and server applications to check them and choose between 3xx redirect and 401 authenticate options, as well as between authentication schemes, based on the presence of those headers. All without changes to HTTP implementations. HTTP implementors will probably want to add support for these headers directly, but that isn't necessary in order to improve interoperability.

The new HTTP auth scheme, Redirect also can be implemented without changes to HTTP implementations, but will be much more useful if implemented at least by user-agents. In the short-term, the HTTP auth scheme, Redirect, is not applicable to any existing protocols or applications. However, existing authentication and authorization systems, such as various Security Assertion Markup Language (SAML) profiles, as well as OpenID Connect (OIDC) and OAuth 2.0 mechanisms in general, such as JWT , can be adapted to use Redirect. Need to add references for SAML. Bibxml does not have any entries for OASIS specs! Specifically, it is better to use headers for communication between relying parties and auth services than it is to use URI query parameters, as the latter imposes on application designers. Besides this, the Redirect auth scheme can greatly simplify adding support for, e.g., JWT, even for non-browser applications. Thus the Redirect HTTP auth scheme is more likely to be useful in the future. Note though that given user-agent support for Redirect, it's fairly easy to adapt SAML/OIDC/JWT identity providers to use it.

Making use of the new Accept-Auth, Accept-Redirect, and Accept-Redirect-Auth request headers will often require no changes to existing HTTP user-agents and servers. This is because the application usually gets to set and inspect arbitrary headers. On the server side it may be difficult for an application to add support for the Redirect authentication scheme without modifying the HTTP server. Therefore it may be difficult for an application to issue a 401 Redirect, and it may have to use a 3xx redirect instead. Therefore, user-agents MUST treat 3xx and 401 Redirect responses similarly, applying the same local policy in either case.

If a server responds with a 3xx and includes not only a Location header but also a WWW-Authenticate header, then the redirect denotes intent to authenticate the user. In this case, the user-agent SHALL consider the response to be either a redirect or a request to authenticate, at the user-agent's choice. The HTTP method to use at the new Location SHALL be as specified for the status code used by the server. Note that many user-agents will not understand that such responses represent an option to authenticate with some authentication scheme.

If a server responds with a 401 and includes not just a WWW-Authenticate header but also a Location header, then the Location header's presence denotes the intent to authenticate the user either via the server's authentication scheme offerings, or redirection. In this case, a user-agent conforming to this specification SHALL consider the response to be either a redirect or a request to authenticate, at the user-agent's choice, and SHOULD pick and execute one of those two options. The user-agent SHOULD use the GET method at the new Location, with the expectation of eventually being redirected back to the original URI authority, at which point the user-agent, if it chooses to retry the original request, SHOULD use the original method. Note that many user-agents will not understand that such responses represent an option to chase a redirection.

We specify here a few OPTIONAL parameters for existing HTTP authentication schemes that user-agents may use to convey relevant information to a server. For the Basic authentication mechanism, user-agents MAY include a "realm" parameter. For the Digest authentication mechanism, user-agents MAY include "realm", "domain", "algorithm", and "qop-options" parameters. For the Negotiate authentication mechanism, user-agents MAY include a "mechs" auth-param whose value is a whitespace-separate list of Object IDentifiers (OIDs) in dotted number notation. For the Redirect authentication mechanism defined here, we define an auth-param, "auth-svcs" whose value is a list of whitespace-separated domainnames that the user-agent will follow redirections to.

Servers that support only one authentication scheme have no difficulty choosing which scheme to use. For other servers, when the user-agent does not include the Accept-Auth header in its request, we have no advice. When a server supports multiple authentication schemes and the user-agent does include the Accept-Auth header in its request, then the server SHOULD select at least one scheme for a 401 response's WWW-Authenticate header that the user-agent also supports, but the server MAY respond with a 3xx redirect response if the user-agent indicated support for redirects via the Accept-Redirect header or by advertising support for the Redirect HTTP authentication scheme.

Ben Kaduk, Simo Sorce, Viktor Dukhovni, Bill Bernsen, Andrew Brown, and Geoffrey Thomas provided feedback and some review.

IANA is requested to assign an expert to run the Expert Review for the registration of the Accept-Auth, Accept-Redirect, and Accept-Redirect-Auth headers in the message header registry. Upon completion of IETF Review, IANA is directed to add the Redirect authentication scheme to the HTTP Authentication Scheme registry. There is no registry for auth-params for HTTP authentication schemes, nor do we request the creation of such a registry. The auth-params used here bear some relation to those of the authentication schemes they are used with, but they are essentially a distinct namespace. Future additions of auth-params for use in the Accept-Auth header will have to update this document.

The Accept-Auth header is security-relevant as it helps negotiate authentication, which is a positive consideration. Negative security considerations include multi-level negotiation issues , as well as a privacy concern: that the Accept-Auth header may help fingerprint user-agents. Privacy-conscious user-agents SHOULD have local policy about which authorities to use the new Accept-Auth, Accept-Redirect, and Accept-Redirect-Auth headers.

The Authorization header preservation behavior allows attackers to convey malformed tokens to victim servers, allowing them to probe for parsing bugs. However, this is already true for the URI itself, therefore this is not a new issue. Open redirectors allow malicious redirects to sites that could set an Authorization header on a redirect back to the site with the open redirector. This would allow an attacker to make a user thing they are logged in as themselves when they are instead logged in as the attacker, and then the victim user might get fooled into sending the attacker sensitive information. This is not a new problem, as it is already a problem for auth systems, such as OIDC, that use URI query parameters to convey cryptographic tokens ("codes" in OIDC parlance). Open redirectors are a security vulnerability in general. Servers MUST NOT implement open redirects. Adding support for channel / token binding to the Redirect HTTP auth scheme may well be possible and desirable. This would consist of request headers set by the user-agent on redirected requests that would carry channel binding (CB) data for one or more CB types corresponding to the original origin (and/or previous hop). One concern is that servers could cause user-agents to engage in authentication schemes they shouldn't want to -- that is a possibility regardless of whether the user-agent advertises support for an authentication scheme or not. As usual, local policy is relevant. For example, the "curl" user-agent by default will not chase redirections, and if enabled, it will by default not authenticate at any redirected authority (this can be further enabled). User-agents SHOULD have local policy about which redirections they will accept, whether to authenticate to redirected authorities, and with what methods. For example, a user-agent may be willing to use the Negotiate authentication scheme at some or any redirected authorities if it is happy to let Kerberos implementations, including Key Distribution Centers (KDCs), apply policy on the user-agent's behalf, but may not be willing to perform Basic , Digest , or SCRAM authentication to any redirected authorities not on a local whitelist.

One important security consideration of the Accept-Auth header is that it may lead to multiple levels of negotiation (e.g., via the Negotiate authentication method). Multi-level negotiations can fail to select to select a workable option, or may select a sub-optimal (e.g., less secure) option. For example, a user-agent might be able to use Digest authentication and Negotiate with some GSS-API mechanism X, while the server might be able to use Digest and Negotiate with some GSS-API mechanism Y, and the server might prefer Y. If the server knows only that the user-agent supports Digest and Negotiate, but not that the user-agent does not support GSS-API mechanism Y, then the server may send a challenge to use Negotiate and then the whole negotiation will fail. In the above example the user-agent could recover by retrying without advertising Negotiate in its Accept-Auth header, but the user-agent is not likely to do this on account of that being too complex. Neither the user-agent nor the server are likely to detect and recover from sub-optimal selections. To avoid this failure more, user-agents SHOULD use auth-params to convey information that the server might need to make an appropriate selection.