Motivating Scenario: A client makes a request to a token endpoint. It uses an
authorization token to authenticate itself and a refresh token to authenticate
it's delegated right. This approach to authenticating clients is used in
enterprises all the time because it's good security practice to send values
derived from a secret (e.g. an HMAC, digital signature, etc.) rather than the
secret itself across the wire, even if the wire is encrypted.
Proposed Text:
2.2 Assertion Client Credentials
The assertion client credentials include a client identifier, assertion and
assertion type. If the assertion client credentials are used then the client
MUST include the credentials using the following request parameters:
client_id
REQUIRED. The client identifier.
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=refresh_token&client_id=s6BhdRkqt3&
client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D&
client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
refresh_token=n4E90119d
The client MUST NOT include the client credentials using more than one
mechanism. If more than one mechanism is used regardless whether the
credentials are identical or valid, the server MUST reply with an HTTP 400
status code (Bad Request) and include the "multiple_credentials" error code.
From: Eran Hammer-Lahav [mailto:[email protected]]
Sent: Friday, June 25, 2010 11:31 AM
To: Yaron Goland; [email protected]
Subject: RE: Clients authenticating with assertions
We never had support for two assertions in one request.
The client authenticates itself and can include an assertion (or use type
'none'). The client credentials are the "client assertion" and the assertion is
about the resource owner.
Also, you can define an assertion type that's a composite assertion (of one
more more).
EHL
From: [email protected] [mailto:[email protected]] On Behalf Of Yaron
Goland
Sent: Friday, June 25, 2010 11:26 AM
To: [email protected]
Subject: [OAUTH-WG] Clients authenticating with assertions
If a client wants to authenticate itself to a token endpoint to get an access
token using an assertion how should it do it?
Grant_Type = assertion doesn't seem right because that assertion should be from
the resource owner who delegated the permission, not from the client, right? In
other words one can end up with an access token request with two assertions,
one from the client and one from the resource owner. How is this done?
Thanks,
Yaron
P.S. I looked for something like client_assertion and client_assertion_type in
section 2 of -08 but didn't see it. Sorry if I missed it.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
