WCF OAuth-不使用RESTFUL服务

Question

I've done some background research into WCF services, and we've decided to look into ways of providing authentication on our services. I suggested OAuth, however we are unsure whether OAuth can be used for WCF services that are NOT RESTful. These would be all over SSL as well.

Can we pass OAuth variables as an object in service calls, alongside our other parameters?

ie

[OperationContract]
public void GetTheAwesome(OAuthObject oauth, AwesomeObject awesome);

[OperationContract]
public OAuthRequestObject Authorise(string username, string pass);

[OperationContract]
public OAuthObject Authenticate(OAuthRequestObject authObj);

[DataContract]
public class OAuthRequestObject
{
    [DataMember]
    public string ConsumerKey { get; set; }
    [DataMember]
    public string ConsumerSecret { get; set; }
}

[DataContract]
public class OAuthObject
{
    [DataMember]
    public string AccessKey { get; set; }  // our key
    [DataMember]
    public string AccessSecret { get; set; }  // our signature/secret
    [DataMember]
    public string Timestamp { get; set; }  // our timestamp
    [DataMember]
    public string SignatureMethod { get; set; }  // our signature method (HMAC/SHA, etc)
}

Is this a valid way for it to occur? Can OAuth even work in this way? Is OAuth restricted to RESTful calls only?

OR

Am I simply overcomplicating things? If I specified to our developers an explicit username/password to include in our other applications, would they function just as well?

Answer 1

The OAuth specification (section 7.1) provides an extensibility point to allow for new access token types and each token type specifies the authentication method(s) that must be used with that token. For example, the "bearer" token type specifies that the token should be attached as an Authorization header of the form "Bearer ".

Here is a link to the spec:

http://tools.ietf.org/html/rfc6749

And here is an snippet from it:

The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes). The client MUST NOT use an access token if it does not understand the token type.

For example, the "bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request:

  GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer mF_9.B5f-4.1JqM 

while the "mac" token type defined in [OAuth-HTTP-MAC] is utilized by issuing a Message Authentication Code (MAC) key together with the access token that is used to sign certain components of the HTTP requests:

  GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC id="h480djs93hd8", nonce="274312:dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" 

The above examples are provided for illustration purposes only. Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC] specifications before use.

Each access token type definition specifies the additional attributes (if any) sent to the client together with the "access_token" response parameter. It also defines the HTTP authentication method used to include the access token when making a protected resource request.

If you are going to implement the Authorisation Server for your services then you are free to define any token type that you want as well as an authentication scheme. Beware of interoperability though. As described, your service will only work with SOAP capable clients and third parties will probably find you a bit hard to deal with.

If you are using an existing 3rd party Authorisation Server, then they will define the token type and you should comply with their authentication scheme.

WS-Trust option

As you are in a .Net/WCF/SOAP world, a better option might be to use WS-Trust/WS-Federation. This is very well supported in WCF with Windows Identity Foundation (WIF). Depending on which .Net version you are using, WIF is either built into the core framework (.Net 4.5) or available as a separate install (.Net 3.5 and 4).

The basic idea of it is that the requests for security tokens and the way they are inserted into SOAP requests when making service calls are standardised. This would replace the Authorise and Authenticate operations with standard ones and replace your explicit OAuthObject parameter with a standard SOAP security header.

Under the hood it is complex, but the WIF implementation abstracts all the complexity away beautifully in my opinion.

An overview can be found here:

http://msdn.microsoft.com/en-us/library/hh291066(v=vs.110).aspx