#928 Proposal: Add PLAINTEXT support to auth protocol

Matthew Giannini Wed 2 Jun 2021

Background

The Haystack Authentication Protocol defines a way for a Haystack client and server to negotiate the authentication mechanism for a user trying to login.  Currently, we define a single auth scheme: SCRAM authentication.

There are use cases where the remote Haystack server is authenticating users against a 3rd party user management system (e.g. LDAP); essentially the Haystack server is acting as an authentication proxy for the client. In this case, it is necessary to send the username and password to the Haystack server, so that the server can authenticate on behalf of the client.

The following proposal defines how we can add support for a plaintext auth scheme to the haystack authentication protocol. It should be noted at the outset, that this scheme only makes sense to use when the connection to the Haystack server is over TLS. 

The following spec is for review and comments:

PLAINTEXT

The PLAINTEXT auth scheme SHALL be used to authenticate the client using a base64url encoded username and password.  Use of the PLAINTEXT scheme MUST only be allowed over a secure TLS connection.

Hello

Note: Header lines have been split to ease readability. All base64url encodings are without padding.  In the following example, a user named user with password password authenticates with the server.

The client sends a hello message identifying the user as user.

C: GET /haystack/about HTTP/1.1   
   HOST: server.example.com   
   Authorization: HELLO username=dXNlcg

The server responds to the client indicating the user should authenticate using PLAINTEXT.

S: HTTP/1.1 401 Unauthorized   
   WWW-Authenticate: PLAINTEXT

The client continues the authentication exchange. The following attributes are included:

  • username: the base64url-encoded username
  • password: the base64url-encoded password
C: GET /haystack/about HTTP/1.1      
   Host: server.example.com   
   Authorization: PLAINTEXT username=dXNlcg, password=cGFzc3dvcmQ

The final server message indicates the user is authenticated. 

S: HTTP/1.1 200 Ok   
   Authentication-Info: authToken=AuthTokenXXYYZZ

Chris Breederveld Thu 3 Jun 2021

Hi Matthew,

Sounds easy enough to implement and may be useful.

However, if I may play devil's advocate here, why not just support Basic authentication? It is less efficient perhaps, but already a commonly used feature in the HTTP protocol.

Brian Frank Thu 3 Jun 2021

However, if I may play devil's advocate here, why not just support Basic authentication? It is less efficient perhaps, but already a commonly used feature in the HTTP protocol.

I think its worth debating. However I have two main issues with standard Basic authentication:

  1. The client sends the username and passwords in plaintext before the server gets a chance to decide the best authentication strategy for the user account
  2. It by-passes the standard plug-in design we already have

In the current design there is one well known flow - the client sends a hello message with the username, then the server decides which authentication scheme to use for the given user.

Chris Breederveld Thu 3 Jun 2021

I agree that this setup is more elegant and probably easier to implement server-side. Just making sure this was at least considered ;-)

Login or Signup to reply.