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:
https://www.rfc-editor.org/rfc/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