5.13 The OPENID20 mechanism

The OPENID20 mechanism makes it possible to use OpenID in SASL, in a way
that offloads the authentication exchange to an external browser. The
protocol implemented is as specified in RFC 6616.

The mechanism makes use of the following properties:
GSASL_AUTHID (for the OpenID User-Supplied Identifier),
GSASL_AUTHZID, GSASL_OPENID20_REDIRECT_URL,
GSASL_OPENID20_OUTCOME_DATA,
GSASL_OPENID20_AUTHENTICATE_IN_BROWSER, and
GSASL_VALIDATE_OPENID20.

In the client, the mechanism is enabled by default. The
GSASL_AUTHID property is required and should contain the
User-Supplied OpenID Identifier (for example
http://josefsson.org). If set, GSASL_AUTHZID will be
used by the client. The client will be invoked with the
GSASL_OPENID20_AUTHENTICATE_IN_BROWSER callback to perform the
OpenID authentication in a web browser. The callback can retrieve the
GSASL_OPENID20_REDIRECT_URL property to find out the URL to
redirect the user to. After authentication, the client can retrieve
the GSASL_OPENID20_OUTCOME_DATA property with the OpenID Simple
Registry (SREG) attributes sent by the server (they are not always
sent).

In the server, the mechanism is enabled by default. The server will
request the GSASL_OPENID20_REDIRECT_URL property, and your
callback may inspect the GSASL_AUTHID to find the OpenID
User-Supplied Identifier. The server callback should perform OpenID
discovery and return the URL to redirect the user to. After this, the
user would access the URL and proceed with authentication in the
browser. The server is invoked with the
GSASL_VALIDATE_OPENID20 callback to perform the actual
validation of the authentication. Usually the callback will perform
some IPC communication with an OpenID consumer running in a web
server. The callback should return GSASL_OK on successful
authentication and GSASL_AUTHENTICATION_ERROR on authentication
errors, or any other error code. If the server received some OpenID
Simple Registry (SREG) attributes from the OpenID Identity Provider,
it may use the GSASL_OPENID20_OUTCOME_DATA property to send
these to the client.

Note that OpenID itself is not implemented by the GNU SASL library. On
the client side, no OpenID knowledge is required, it is only required on
the server side. The client only needs to be able to start a browser
accessing the redirect URL. The server side is expected to use an
OpenID library of your choice to generate the redirect URL and to
implement the Service Provider to validate the response from the IdP.
There is a complete proof-of-concept example with a SMTP server with
OpenID 2.0 support distributed with GNU SASL in the examples/openid20/
sub-directory. It uses the JanRain PHP5 OpenID implementation. The
example may be used as inspiration for your own server implementation.
The gsasl command line client supports OPENID20 as a client.