For intranet applications that already leverage Active Directory, is there any point or benefit to adding a second layer of security such as OAuth when accessing SOA REST services? We're new to SOA and REST and are fairly unguided as to how to secure our services.
Assuming all your accounts are stored in Active Directory, and only AD, and you will not accept any account registered at an external provider, it's hard to see additional benefit of simply using OAuth solely as the protocol to authenticate* users registered on your AD.
OAuth has a different use-case, it is designed to fit for federation scenarios:
It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials.
In your case, there is no need to share credentials in the first place, since the client machine, the server application, and the user accounts are all registerd in AD to begin with. SSPI (aka Windows Integrated Authentication) would probably fit your needs just as well.
There are a few downsides, though, to just using WIA/AD out of the box - for one, having transparent user authentication (via WIA) can lead to some other weaknesses, such as CSRF (doesn't cause it directly, but it definitely makes it much easier to exploit).
Depending on how you were thinking of implementing OAuth, this may or may not have mitigated this issue. Regardless, there are other better solutions than OAuth (which has it's own complexities).
There are also possible AD issues to consider, however your proposed solution (OAuth+AD) would not have affected this anyway.
So, bottom line - I don't see any benefit in sticking OAuth in there.
If there is a specific risk you're worried about with WIA, there are probably better / easier solutions.