This contains some protocol changes to SASL authentiation (which is new in v10):
- For future-proofing, in the AuthenticationSASL message that begins SASL authentication, provide a list of SASL mechanisms that the server supports, for the client to choose from. Currently, it's always just SCRAM-SHA-256.
- Add a separate authentication message type for the final server->client SASL message, which the client doesn't need to respond to. This makes it unambiguous whether the client is supposed to send a response or not. The SASL mechanism should know that anyway, but better to be explicit.
Also, in the server, support clients that don't send an Initial Client response in the first SASLInitialResponse message. The server is supposed to first send an empty request in that case, to which the client will respond with the data that usually comes in the Initial Client Response. libpq uses the Initial Client Response field and doesn't need this, and I would assume any other sensible implementation to use Initial Client Response, too, but let's follow the SASL spec.
Improve the documentation on SASL authentication in protocol. Add a section describing the SASL message flow, and some details on our SCRAM-SHA-256 implementation.
Document the different kinds of PasswordMessages that the frontend sends in different phases of SASL authentication, as well as GSS/SSPI authentication as separate message formats. Even though they're all 'p' messages, and the exact format depends on the context, describing them as separate message formats makes the documentation more clear.
Reviewed by Michael Paquier and Álvaro Hernández Tortosa.
4f3b87a Improve the SASL authentication protocol.
doc/src/sgml/protocol.sgml | 418 ++++++++++++++++++++++++++++++++++++++---
src/backend/libpq/auth-scram.c | 27 ++-
src/backend/libpq/auth.c | 68 ++++++-
src/include/libpq/pqcomm.h | 5 +-
src/interfaces/libpq/fe-auth.c | 158 +++++++++++-----
5 files changed, 588 insertions(+), 88 deletions(-)