The following is proposed language for inclusion in the spec as section 2.2. I
would like to thank Brian Campbell, Brain Eaton, Chuck Mortimore, Dirk Balfanz,
Eric Sachs, Justin Smith and Marius Scurtescu for taking the time to review and
improve this proposal. Please note that the named folks contributed the good
ideas and I just focused on introducing anything that is broken.
So what does the group think? +1? -1?
Thanks,
Yaron
2.2 Assertion Client Credentials
While Client Passwords provide a simple mechanism for authenticating clients
they require that a secret, the password, be sent over the network. Even when
the network connection is encrypted sending secrets over a network connection
is considered a potentially serious security threat. In scenarios where
security is at a premium, it is preferred to use mechanisms such as Hash-based
Message Authentication Codes (HMACs) or digital signatures that do not require
sending secrets across the wire. The most common way to use HMACs or digital
signatures is in assertions. Therefore this section defines how to authenticate
a client using an assertion instead of a password.
The following parameters are used when a client authenticates itself using an
assertion:
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 (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_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
In the previous example the client is submitting an authorization code to a
token endpoint using a SAML assertion to authenticate itself.
The client_id and client_secret parameters MUST NOT be used with the
client_assertion and client_assertion_type parameters.
Requests for end user authorization as defined in section 3 are required to
contain a client_id parameter. If the response to the authorization request is
a code then that code is submitted to a token endpoint to obtain an access
token. For this flow to work with assertions there must exist some mechanism to
map the value in the client_id parameter of the authorization request to the
assertion that is subsequently submitted with the code to get an access token.
How this works with any particular assertion type is out of scope for this
document. However, any document that defines how to use an assertion of a
particular type with OAuth 2.0 MUST define how to map the value from the
client_id parameter in the authorization request to a value or values in the
assertion subsequently submitted with the code to obtain an access token.
Token endpoints MUST reject assertions that do not contain HMAC/signed values
that identify that the assertion is specifically intended to be consumed by the
receiving endpoint. This requirement is typically met by some value in the
assertion such as audience or recipient which contains the token endpoint's URI
or other agreed upon identifier.
Token endpoints MUST reject assertions that do not contain HMAC/signed values
that identify the entity that generated the assertion. This requirement is
typically met by some value in the assertion such as issuer which contains a
URI or other agreed upon identifier that identifies the entity that generated
the assertion.
Token endpoints MUST reject assertions that do not contain HMAC/signed values
that identify when the assertion is to expire as an absolute time. This
requirement is typically met by some value in the assertion such as expiration
that contains a UTC date/time value or equivalent time stamp identifying when
the assertion will expire. Token endpoints MUST reject assertions whose
expiration time is beyond a certain limit in the future. The definition of that
limit MUST be based on the security requirements of the resource being
protected. The limits to choose for any particular type of resource/data are
application specific and depend upon a combination of what technologies are
being used, what key policies are being followed, what laws may apply, etc. and
therefore are out of scope for this document.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
