---

5.3 The PLAIN mechanism

The PLAIN mechanism uses username and password to authenticate users. Two user names are relevant. The first, the authentication identity, indicates the credential holder, i.e., whom the provided password belongs to. The second, the authorization identity, is typically empty to indicate that the user requests to log on to the server as herself (i.e., the authentication identity). If the authorization identity is not empty, the server should decide whether the authenticated user may log on as the authorization identity. This is typically used for super-user accounts like ‘admin’ to take on the role of a regular user.

In the client, this mechanism is always enabled, and require the GSASL_AUTHID and GSASL_PASSWORD properties. If set, GSASL_AUTHZID will also be used.

In the server, the mechanism is always enabled. Two approaches to authenticate and authorize the client are provided.

In the first approach, the server side of the mechanism will request the GSASL_VALIDATE_SIMPLE callback property to decide whether the client should be accepted or not. The callback may inspect the GSASL_AUTHID, GSASL_AUTHZID, and GSASL_PASSWORD properties. These property values will be normalized.

If the first approach fails (because there is no callback or your callback returns ‘GSASL_NO_CALLBACK’ to signal that it does not implement GSASL_VALIDATE_SIMPLE) the mechanism will continue to query the application for a password, via the GSASL_PASSWORD property. Your callback may use the GSASL_AUTHID and GSASL_AUTHZID properties to select the proper password. The password is then normalized and compared to the client credential.

Which approach to use? If your database stores hashed passwords, you have no option, but must use the first approach. If passwords in your user database are stored in prepared (SASLprep) form, the first approach will be faster. If you do not have prepared passwords available, you can use the second approach to make sure the password is prepared properly before comparison.

The PLAIN mechanism was initially specified in RFC 2595 and later revised in RFC 4616.