To make discussion easier, here is the proposed text:
[NOTE: Text for the following Section 3 is based on OAUTH draft-11]
3. Client Credentials
When interacting with the authorization server, the client identifies
itself using a set of client credentials which include a client
identifier and other properties for client authentication. The means
through which the client obtains its credentials are beyond the scope
of this specification. Some authentication
schemes require the client to undergo registration with the
authorization server.
Due to the nature of some clients, authorization servers SHOULD NOT
make assumptions about the confidentiality of client secrets without
establishing trust with the client. Although it is difficult for
servers to ascertain the security capabilities of clients, in general
authorization servers SHOULD NOT issue client secrets to clients incapable
of keeping their secrets confidential.
The authorization server MAY authenticate the client using any
appropriate set of credentials and authentication schemes. The
client MUST NOT include more than one set of credentials or
authentication mechanism with each request.
Although authentication schemes and their protocol implementations
are out of scope, this specification seeks to support a broad
selection of authentication schemes that are currently deployed
today and that may be deployed in the future.
3.1. Client Password Credentials
Client password credentials use a shared symmetric secret to
authenticate the client. The client identifier and password are
included in the request using the HTTP Basic authentication scheme as
defined in [RFC2617] by including the client identifier as the
username and client password as the password.
For example (line breaks are for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Alternatively, the client MAY include the password in the request
body using the following parameters:
client_id
REQUIRED. The client identifier.
client_secret REQUIRED. The client password.
For example (line breaks are for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST accept the client credentials using
both request parameters and the HTTP Basic authentication scheme.
The authorization server MAY support additional authentication
schemes suitable for the transmission of password credentials.
3.2. Shared Secret Credentials
Beyond client password credentials, there is a broad family
of authentication schemes based on the notion of shared secrets.
In these schemes the primary aim is for the client to prove
possession of the shared secret. In the current OAUTH 2.0 context,
shared secret credentials are different from assertion credentials
(see below) in that here the client does not have to
provide any assertions or claims.
Within the family of authentication schemes based on the pairwise
sharing of secrets there are a variety of protocols that have
been deployed. These include challenge-response protocols
(e.g. CHAP [RFC1994]), password-authenticated key agreement
protocols (e.g. EKE [REF]) and various embodiments
of the one-time password (OTP) protocols (e.g. [RFC2289]).
These authentication protocols
are out of scope of this specification, but in deployment
of these authentication schemes with OAUTH 2.0, the authorization
server MUST accept the client credentials using
both request parameters and the HTTP Basic authentication scheme.
3.3 Client Assertion Credentials
The term assertion (or signed assertion) refers to a statement or
claim made by a trusted third party regarding a given subject
at a given moment in time. Typically an assertion is digitally
signed by its issuer in order to provide source-authenticity
and integrity protection. There are a number of vehicles for
the implementation of assertions.
Examples include X.509 subject and attribute certificates
[RFC3280,RFC5755], SAML 2.0 assertions [OASIS.saml-core-2.0-os],
Claims [OASIS.imi-identity-1.0], Kerberos service tickets [RFC4120] and
others.
Their differences typically lie in their semantic expressiveness,
syntactic complexity and size.
In OAUTH, client assertion credentials provide an extension point
by which the authorization server can authenticate a client by validating
a signed assertion issued by a third party (assertion issuer),
which is trusted by both the client and the authorization server.
A client must obtain an assertion (such as
a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer
or may in some cases self-issue an assertion.
The format of the assertion, the process by
which an assertion is obtained, and the method of validating an
assertion are defined by the assertion issuer and the authorization
server, and are beyond the scope of this specification. However, for
the purposes of the authorization server validating the identity of
a client, the assertion presented by the client SHOULD contain
at least the following information:
o Identity of the client.
o Identity of the issuer.
o Method of authentication used by the issuer to
authenticate the client (RECOMMENDED).
o Time of authentication of the client by the issuer (RECOMMENDED).
o Time of assertion issuance and validity period of assertion.
o Digital signature of the issuer.
o An indication (explicit or implied) as to the means by which
the client demonstrates its right to present the assertion (RECOMMENDED).
When using a client assertion, the client includes the following
parameters:
client_assertion_type REQUIRED. The format of the assertion as
defined by the authorization server. The value MUST be an
absolute URI.
client_assertion REQUIRED. The client assertion.
For example, the client sends the following access token request
using a SAML 2.0 assertion to authenticate itself (line breaks are
for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1&
client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D&
client_assertion_type=
urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
When obtaining an access token using a client assertion together with
an authorization code (as described in Section 5.1.1), a mechanism is
needed to map between the value of "client_id" parameter used to
obtain the authorization code, and the client assertion. Such a
mechanism is beyond the scope of this specification, but MUST
be specified for any client assertion type used in combination with
an authorization code.
The authorization server MUST reject access token requests using
client assertion credentials that do not contain HMAC or signed
values that:
o State the assertion was specifically issued to be consumed by the
receiving endpoint (typically via an audience or recipient value
containing the receiving endpoint's identifier).
o Identify the entity that issued the assertion (typically via an
issuer value).
o Identify when the assertion expires as an absolute time (typically
via an expiration value containing a UTC date/time value). The
authorization server MUST reject expired assertions.
References
RFC1994. PPP Challenge Handshake Authentication Protocol (CHAP), IETF
Standards Track, August 1996.
S. M. Bellovin; M. Merritt (May 1992). "Encrypted Key Exchange: Password-Based
Protocols Secure Against Dictionary Attacks". Proceedings of the 1992 IEEE
Symposium on Research in Security and Privacy, Oakland, CA.
RFC4120. The Kerberos Network Authentication Service (V5), IETF Standards
Track, July 2005.
OASIS Identity Metasystem Interoperability Version 1.0, Oasis Standard, July
2009. URL:
http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.html#_Toc229451842
RFC5755 An Internet Attribute Certificate Profile for Authorization, IETF
Standards Track, January 2010.
RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, IETF Standards Track, April 2002.
RFC2289. A One-Time Password System. IETF Standards Track, February 1998.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
