James,
Yes, I understand you now and I agree with you.
With thanks,
Igor
Manger, James H wrote:
Igor,
.... Adding client_id here is unnecessary (the server can include it
in the token if it is convenient for protected resources), and harmful
(it means the protocol that uses the credentials from the token
response cannot look like a normal authentication protocol).
Could you please clarify the last point (i.e., "cannot look like a
normal authentication protocol")? I simply don't understand what you mean.
Perhaps an example would help. Consider a server (of protected resources) that
authenticates requests using the HTTP DIGEST scheme (or substitute any other
request signing scheme that is not OAuth-specific).
If it wants, the server can authenticate requests directly from users: by
returning WWW-Auth: DIGEST... to trigger the browser to prompt the user for
their password.
To support delegated access (requests from a client app on a user's behalf) the
server tells the client app to orchestrate an OAuth2 flow. The client app ends
up with a token response that contains credentials to use with the HTTP DIGEST
scheme (ie a user-id/password pair that represents this delegation).
The client app now makes requests on the user's behalf to the server using
"normal" HTTP DIGEST. On the wire, these requests are totally standard HTTP
DIGEST authentication requests (so they can use totally standard implementations and
APIs).
There is no extra client_id field in the HTTP DIGEST scheme. It does take an id, but in
this context that is the id of the delegation (client app X acting for user Y). DIGEST
assumes a model with two parties that shared a secret -- it simply has no use for the
extra concept of a third party, and neither will any other "normal"
authentication protocol.
I believe the SASL model is a bit more sophisticated. It includes 2 ids: an
authentication_id and an authorization_id. But neither of those would
correspond to client_id. The authorization_id could be a bearer token (when
there is no authentication_id); or the authentication_id could be the id from a
token response that had a secret key (and the authorization_id could be the
user-id).
If the OAuth framework spec forced an explicit client_id parameter into
requests for protected resources it would be unusable with HTTP DIGEST (and
every other authentication scheme, past and future, that is not OAuth-specific).
Is my meaning any clearer now?
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
