I have two enterprise servers which need to communicate in a secure way, and am comparing using SSL (with client/server certs to validate both sides) vs two-legged authentication using OAuth 2.0 (optionally with MAC tokens or JWT tokens).
Historically OAuth seems to have been created for a totally different purpose (the 3-legged case where a user is allowing a service to access some data somewhere), and although two-legged is now integrated into the OAuth 2.0 spec, from what I have seen two-legged OAuth 2.0 doesn't seem to offer much additional protection over SSL.
The only point I can think of is that OAuth is potentially easier to configure than SSL, and it is easy to make mistakes with things like accepting bad SSL certs which can compromise security. However I am not sure if this is reason enough to go with OAuth.
Note that I mention these as separate options, but I think using OAuth would probably entail using it on top of HTTPS/SSL, so both would be used.
Is there any real advantage of using OAuth 2.0 two-legged scheme for server-to-server communication (no user involved)?
Note: I did find a a somewhat similar post here, but that is quite old but I don't feel that gave a satisfactory answer on this matter.
Apologies if you already know this but it isn't clear in your post.
OAuth and SSL\TLS are two separate layers of the OSI model. OAuth is for authentication and is at the top in Layer 7 while SSL\TLS is for transport security in layer 4. It's easy to confuse SSL with client certificates because they both use PKI.
You are correct in your understanding of OAuth...it is used for authorizing individuals not organizations\servers. 2-legged OAuth is a term that is thrown around which encompass various alternate OAuth flows, all of which do not follow a standard.
In my opinion, you want to use client certificates to secure your server-server communication...all that is really required is a single x509 certificate that can be used as both SSL (transport security) and client certificate (authorization); although using 2 certificates is the norm.
I'll respond to this comment:
My question is that, assuming I am using SSL with proper client/server certs to identify each machine, what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved). Thanks – Locksleyu
Summary: I wouldn't bother doing both.
Details: 2-legged OAUTH is only as secure as the consumer secret is. Similarly mutual auth SSL is only as secure as the private key. I assume that you'll be storing these in some encrypted store on each server. As both are stored in the same place I see no additional security that comes from adding OAUTH.
Now if you are considering a choice between mutual auth SSL and standard SSL with authentication, perhaps OAUTH can play a role there. I would go with whichever of those options seems easier. So if you have an OAUTH system in place and can easily add server auth to it, perhaps that's the way to go. Otherwise, just go with mutual auth SSL. It tends to be a bit of a hassle to configure but works well and quickly once set up.
To answer your question "what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved)."
You may refer below
https://salesforce.stackexchange.com/questions/93887/mutual-authentication-two-way-ssl-oauth
Related
I have a web application which is developed using vb.net.
My web application uses Windows authentication mode.
Security team scanned the application and reported one issue.
Steps followed to produce the issue:
1. Type the url in browser (url - https://sample/applicationname) and press Enter
2. Analyze the response using proxy tool 'Fiddler' - which shows that authentication method in NTLM which is insecure.
Recomendations given by security team:
Change authentication method to a more secure one such as Digest, client certificates or similar. Otherwise use an encrypted channel to protect information by implementing HTTPS.
Note: HTTPS is already implemented.
Kindly let me know how to solve the issue.
Thanks in advance.
Digest is less secure than NTLM, so you may want to mock your security team. Digest uses MD5 (in a weak manner) and requires reversible passwords. If you really want to go more secure than NTLM, your may want to configure kerberos. The options vary depending on your version of IIS. Google will have your answer.
Hi guys this is my first time trying to handle Oauth in my project. I have read the tutorials on link. I have tried Google and Facebook Oauths and amazed by how simple it is. Now I am going to try Twitter / Yahoo / Microsoft just for learning purposes. This question might land me negative points as it is a learner question. So my question is when using Facebook Oauth you need the SSL Https URL for LocalHost machine. How about Yahoo/ Twitter/ Microsoft. Which one needs SSL.
When using OAuth, you should use SSL. As a matter of fact, Twitter requires SSL on all of their endpoints as of today. If you study the protocol, you'll see that there are tokens being passed back and forth in the Authorization header. You'll want to protect those. You also want protection on the responses from the provider, which contain tokens and other info. Some applications might not require SSL (though Twitter does now), it's best practice to be secure by design, secure by default, and secure in deployment.
No - your localhost machine does not need to be running SSL.
Indeed, even if you're not using localhost, there's no obligation to use SSL. Theoretically, there's little risk if your tokens do get intercepted, because your private tokens never leave your machine.
So, the OAuth dance can be
User -> Your Website -> SSL to OAuth provider -> Redirect to localost (non SSL)
I was wondering if the twisted webserver offers the possibility to restrict access to some resources using client certificate based authentication and to allow access to other resources without certs.
I searched trough the questions and found this posting: Client side SSL certificate for a specific web page
Now my question is if someone knows if twisted has implemented the ssl renegotiation and how an example would look like.
Or has there been a different approach since then?
Just to make things clear and to give additional information:
What I actually want to achieve is something like this:
A new user visits a site and has not yet granted access to the resource because he has no token yet that allows him to view the site.
Therefore, he gets redirected to a login resource that is asking for a client certificate. If everything is correct, additional data retrieved from the certificate is stored in the session, which makes up the token.
He then gets redirected back to the entry site, the token is validated, and according to his authorization level specific content is displayed
If I understood you correct Jean-Paul, this seems to be possible to implement with your strategy, right?
Correct me if I'm missing something or doing it wrong.
It doesn't seem to me that SSL renegotiation is particularly applicable here. What you actually want to do is authorize a request based on the client certificate presented. The only reason SSL renegotiation might be required is if you want the client to be able to request multiple resources over a single persistent HTTPS connection, presenting a different client certificate for each. This strikes me as unlikely to be necessary (or at least, the reasons for wanting this - rather than just letting the client establish a new HTTPS connection, or just authorizing all your resources based on a single client certificate - are obscure).
Authorization in Twisted Web is straightforward. Many prefer a capability-like approach, where the server selects a resource object based on the credentials presented by the client. This resource object has complete control over its content and its children, so by selecting one appropriate for the credentials presented, you completely control what content is available to what clients.
You can read about twisted.web.guard in the http auth entry in the web in 60 seconds series.
This will familiarize you with the specifics of authentication and authorization in Twisted Web. It will not tell you how to authenticate or authorize based on an SSL client certificate, though.
To do that, you'll need to write something similar to HTTPAuthSessionWrapper - but which inspects the client SSL certificate instead of implementing HTTP authentication as HTTPAuthSessionWrapper does. This will involve implementing:
IResource to inspect the transport over which the request is received to extract the client certificate
implementing a credentials type which represents an X509 certificate
implementing a credentials checker which can authenticate your users based on their X509 certificate
and possibly implementing a realm which can authorize users (though you may have written this already, since it is orthogonal to the authentication step, and therefore is reusable even if you don't want to authenticate with SSL certificates)
This functionality would be quite welcome in Twisted itself, so I'm sure you can find more help from the Twisted development IRC channel (#twisted-dev on freenode), and I hope you'll contribute whatever you write back to Twisted!
I have created a REST API that uses Basic HTTP authentication. Is is restricted to SSL only. Now that it is implemented I am hearing criticisms that Basic HTTP over SSL is not secure. It would be detrimental to the project for me to "stop the press" and it would be outside the scope of some of my clients skill set to use OAuth, etc. I need to understand the risk and rewards of this methods. Any examples of big names using Basic HTTP auth would be helpful as support also.
Basic HTTP authentication over SSL is basically secure, with caveats. Security issues predominantly arise from the use of Basic auth without SSL, in which case, the username and password are exposed to a MITM. In a browser, there are also problems with expiring credentials, but this isn't so much of an issue for REST services.
perhaps I am mislead but I don't see a problem with SSL only BASIC... esp. not with a stateless API.
If the callers are forced to use a SSL-sniffing proxy then BASIC means that the password is available in cleartext to the proxy... in this specific case Digest would be better (even with SSL) because the proxy wouldn't know the password (digest means challenge response...).
so I'm currently trying to make an OpenID provider. I've tried using two Java based OpenID server packages- Atlassian's Crowd, and WSO2 Identity Server. Now, in my implementation, security is a must, which means using SSL and having HTTPS based OpenIDs. Now, for both WSO2 and Crowd a large number of sites simply do not work with the OpenIDs provided. Of 20 sites tested, 8 failed with Crowd, and 10 failed with WSO2. This high failure rate is not really acceptable. Virtually every site which has a problem claims that they cannot find an OpenID endpoint.
When I used the OpenIDs without SSL (so HTTP based OpenIDs) suddenly the sites were far more compliant, with only two of them failing. I am using a certificate from AusCERT, so the problem should not be due to self-signed certificates.
At first I thought that this was just a matter of there being a large number of RPs which simply did not accept HTTPS based OpenIDs. I tried logging into the same sites I was failing on with an HTTPS based OpenID from Verisign though, and it worked. Looking closer at both WSO2 and Crowd I discovered that neither completely conformed to OpenID 2.0 specification- in particular, neither of them provide a link in the head to an XRDS document for yadis discovery. Considering that my problem is that sites cannot discover an OpenID endpoint at the URL I give, it seems relevant except that when I do not use SSL the HTML based discovery is sufficient.
Does anyone have any insight as to where my problem really lies? The missing XRDS document seems like it should be relevant, but it could just be a red herring. Baring that, if anyone knows a good alternative to Crowd or WSO2 which is well documented, works well to spec, and is (relatively) easy to configure, it would be nice to know!
One thing to look at is that some Providers' SSL certificates are not signed by root authorities that are considered authoritative by some RPs. Make sure you get your certificate from one that all RPs trust.
If .NET is an option for your provider, check out the free and open source DotNetOpenAuth library, which you can host yourself and is used by some major OPs such as MySpace and netidme.com and others. It's implementation of OpenID 2.0 is complete, it supports the U.S. government ICAM OpenID 2.0 Profile, and has been used for many interoperability, security and compliance tests, and it works with both OpenID 1.1 and 2.0 RPs so you'd be very likely to have good interoperability with many/all RPs. It has a bunch of additional security features that you can just switch on (like requiring HTTPS as you said is a requirement).
(Full disclosure: I wrote DotNetOpenAuth.)