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:
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). So, bottom line - I don't see any benefit in sticking OAuth in there. |
|||
|
|