This is pretty straight-forward. There are no special parameters to indicated which client authentication is being used. It's either there or not, using whatever the server supports.
Simply have the token endpoint return a 401 with these WWW-Authenticate headers. As long as you make it clear how to make between the client identifier and the credentials used, you are set. For example, a token response can return: 401 Unauthorized WWW-Authenticate: Basic realm="example" WWW-Authenticate: Digest realm="example" There is no discovery for support for the client_id and client_secret parameters. The client can simply try it or hardcode it based on the server's documentation. Does this help? EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, January 24, 2011 1:10 PM > To: OAuth WG > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? > > Hi all, > > I'm currently thinking about the integration of existing HTTP authentication > schemes with OAuth 2.0 for the purpose of end-user authentication on the > tokens endpoint. Possible candidates are "Digest" > for challenge-response-based username/password authentication and > "Spnego" for Kerberos-based authentication. Direct support for both could > be beneficially in enterprise and other security sensitive deployments. > > An direct integration with the tokens endpoint would allow to leverage > existing implementations and infrastructure for OAuth/HTTP-based > architectures. For example, HTTPClient has direct support for Spnego- > Authentication. > > Both HTTP authentication schemes use dedicated WWW-Authenticate and > Authorization headers for passing credential and other data between client > and server. OAuth in contrast uses grant types to indicate the authentication > method, credentials are passed as URI query parameters and it lacks any > discovery of available authentication methods/ grant types. > > How could one integrate existing schemes into that design? What is our > story? Do we need to define a special grant type "HTTP authorization"? > Shall Authorization headers overrule URI parameters? > > Any ideas of the WG are higly appreciated. > > regards, > Torsten. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
