Subject: [OAUTH-WG] authorization id in SASL mechanisms

From: "Manger, James H" <[email-masked]>
Date: Fri, 4 Dec 2009 00:57:40 +1100

I noticed that a number of existing authentication schemes support an authorization id, in addition to an authentication id. This model might be applicable to any OAuth authentication mechanisms as the result from an OAuth delegation flow looks like a perfect candidate for the authorization id field.

A prime example using these two identities is RFC 4422 Simple Authentication and Security Layer (SASL).

   “… conceptually, the SASL framework involves two identities:

      1) an identity associated with the authentication credentials

         (termed the authentication identity), and

      2) an identity to act as (termed the authorization identity).

   SASL mechanism specifications describe the credential form(s) (e.g.,

   X.509 certificates, Kerberos tickets, simple username/password) used

   to authenticate the client, including (where appropriate) the syntax

   and semantics of authentication identities carried in the

   credentials.  SASL protocol specifications describe the identity

   form(s) used in authorization and, in particular, prescribe the

   syntax and semantics of the authorization identity character string

   to be transferred by mechanisms.

   The client provides its credentials (which include or imply an
   authentication identity) and, optionally, a character string
   representing the requested authorization identity as part of the SASL
   exchange.  When this character string is omitted or empty, the client
   is requesting to act as the identity associated with the credentials
   (e.g., the user is requesting to act as the authentication identity).

   The server is responsible for verifying the client's credentials and
   verifying that the identity it associates with the client's
   credentials (e.g., the authentication identity) is allowed to act as
   the authorization identity.  A SASL exchange fails if either (or
   both) of these verifications fails.  (The SASL exchange may fail for
   other reasons, such as service authorization failure.)”

SASL is a framework, and there are a handful of specific SASL mechanisms defined. Of particular relevance to OAuth are: EXTERNAL [RFC 4422 Appendix A] and PLAIN [RFC 4616]. There are also digest-like mechanisms.

EXTERNAL is basically a bearer token. It carries an authorization id, but no client authentication.

PLAIN sends an authorization id, authentication id (eg client id), and password in the clear.

SASL is designed for connection-oriented protocols so it is not directly suitable for message-oriented HTTP. However, the concept of authorization and authentication identities might be a good way to frame any OAuth authentication mechanisms.

--

James Manger