Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth)

First I'd like to emphasize the difference between authentication and authorization:

A user authenticates to your web site by supplying some credential such as a username+password. OpenID allows this to be displaced by having the user authenticate to another service, which then asserts the user's identity to your web site on the user's behalf. Your site trusts the third party service (the OpenID Provider) and therefore considers the user logged in.

A service or application does not authenticate to your web site -- at least not typically. A user authorizes a service or application to access the user's data. This is typically done by the application requesting authorization of the service provider, then sending the user to the service provider, where the user first authenticates (so the service provider knows who its talking to) and then the user says to the site "yes, it's ok for [application] to access my data [in some restricted way]". From then on, the application uses an authorization token to access the user data on the service provider site. Note that the application does not authenticate itself as if it were the user, but it uses another code to assure the service that it is authorized to access a particular user's data.

So with that distinction clarified, you can make decisions on your site about authentication and authorization completely independently. For instance, if you want your users to be able to log in with all of: username+password, OpenID, and Facebook, you can do that. A completely orthogonal decision is how you authorize applications (there are many protocols you can use for this, OAuth of course being quite popular).

OpenID is focused on user authentication. OAuth is focused on application authorization. However, a few services such as Facebook and Twitter have chosen to use OAuth for authentication and authorization instead of using OpenID for authentication and OAuth for authorization.

Now for your own project, I strongly recommend you check out the ASP.NET MVC 2 OpenID web site (C#) project template available from the VS Gallery. Out of the box it comes with OpenID authentication and OAuth Service Provider support. This means your users can log in with OpenID, and 3rd party applications and services can use OAuth to make API calls to your web site and access user data.

What it sounds like you'd want to add to this project template once you get going is the ability for your users to log in with username+password as well as OpenID. Also, if you want Facebook and Twitter to be an option for your users you must implement that as well since they don't use the OpenID standard. But the DotNetOpenAuth download includes samples for logging in with Twitter and Facebook so you have some guidance there.

I suspect you won't have much if anything to do on the authorization front. It comes with OAuth as I said before, and that will probably suffice for you.

First of all. You need to mentally separate what is your API - from methods of authentication.

Your API is basically resources, and methods to manipulate those resources. And you can have several methods of authenticating access to you API.

OAuth is one such authentication mechanism. Being an OAuth provider is great, even though the specification is a little hard to grasp, especially the parts that have to do with signatures. Once you have OAuth in place, client applications usually have an easy time authenticating, since there are so many "open source, already done, just implement" libraries available in most languages.

The pros and cons of OAuth have been debated for a while. But to form your own opinion I suggest reading this definitive guide, written by Eran Hammer-Lahav, one of the people responsible for the OAuth specification.

The only real alternatives to OAuth as far as I see it, are OAuth 2.0 and just simple basic authentication.

Other than that, you are talking about authenticating using Open-ID, or facebook identity etc. This is yet another question you need to ask yourself. But it really falls outside the scope of APIs and OAuth. To me, that feels more of a question of user creation in your service. I may be wrong.