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)
Related
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
I am writing an HTTPS web server using express.js. It does not have super secure, I think ssl certificates is overkill and not a good option for client apps. I have routes for my restAPI. There will be a login page. So I will have a user/password pair available to me.
Can I use this information alone to allow access to my HTTPS routes ?
I think you're asking whether basic auth over https is secure. The answer is yes, that's a reasonable security architecture, and is widely used for authenticating APIs. It's fine to route based on the basicAuth credentials. If you start worrying more about security, focus on how to safely store passwords.
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...).
I'm running a dating site and not using SSL at the moment.
I've noticed major sites like facebook and twitter do not use https for login but just use plain old http, is there really any advantage to https-ing my site or it is only for cc transactions or so ?
thanks in advance.
Actually, facebook does use https for its login:
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
as does twitter:
<form method="post" id="signin" action="https://twitter.com/sessions">
You'll notice they don't use https for the page that displays the signin form. That's because it isn't necessary.
However, it's a good idea to use ssl the login itself if you can, if only because so many users employ the same password for all sites.
One solution, which I'd like to see more sites employ, is using OpenID/OAuth for login instead of requiring a username/password.
SSL encrypts the traffic between the browser and the server. So virtaully anything you want to be secure needs to be ssl'ed. Google search is even doing it so poeople can't have their search terms intercepted.
Its just the case of what YOU want secure, and if not having certain parts of your site secure will keep wanted customers away. I would think a dating site has a lot of personal demographics information that some people might want secure... just my 2 cents.
SSL is used only when transmitting sensitive data between browser and server. It's fine for major sites like facebook and twitter to use http (as long as the data is not sensitive). Most website use SSL for their login page. SSL also used by payment gateway to safely transfer payment information through the wire.
And by the way, http is not "plain old" and https is not new trend either :)
If your users are providing any sensitive data, ssl prevents it from being intercepted by a third party. If you don't use SSL, you should assume that some third party can see everything that every one of your users does on your website. If you are comfortable with them seeing this information, then keep it plain http, but if you don't like that thought, go https.
Another benefit of ssl is that it allows the use of Strict Transport Security, which not only forces https on all site activity, but also prevents a man in the middle from spoofing your site to a user and making them think they are accessing your site. Details here: http://en.wikipedia.org/wiki/Strict_Transport_Security
I work at a major ISP and am infatuated with one of your online members. By sniffing your packets, I can find out when and where she's meeting another member, rewrite the packet to change the location so the other guy doesn't show up, and then make my move.
You decide whether that's acceptable to your users.
Https is useful to protect the credential (user/password) , but it increases the network load and requires more CPU resource (encryption). Thus, it is common to use only for authentication.
Https ,with server certificate protects again phising.
Banks uses end to end application
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.)