views:

50

answers:

2

Hi, I'm planning a web service and doing a little research about what are current methods of secure user authentication.

Is what Google and Facebook are doing considered an industry standard?

+1  A: 

it depends what kind of securiry you need, but it general the authentication protocol is the last thing that breaks. Implementation flaws are exploited much more often.

If you need security for a webservice and you need more than simple username and password (with password strength policy), consider

  • ssl (with mutual authentication)
  • kerberos
  • zero knowledge protocols (lightweigth)

but again, whatever you choose, dont make it to complicated and make sure the implementation is secure, since your security is as good as the weakest point

Henri
sounds like Kerberos and Zero Knowledge protocols apply to client-server communication where both are machines. I'm actually talking about user authentication via a browser.
SODA
+2  A: 

Authentication to a "web service"... Do you mean SOAP/HTTP(S) or web page? The answers are different in the two cases!

  • For SOAP/HTTPS, you're talking using the WS-Security suite with SAML/XACML tokens. The authority could be derived in a number of ways such as Kerberos or VOMS. This is distinctly non-trivial and you'll need to work out what all the other pieces in the "ecosystem" of services are up to and ensure that you interoperate with that.
  • For web-pages, check out either OpenID or Shibboleth as ways to derive authentication tokens from sources maintained by others. As I understand it, OpenID is better for the open internet and Shibboleth is better for corporate deployments (it was designed for dealing with problems like handling webpage login for universities).

If you're doing a webpage that acts as a portal to secured webservices, it's possible to bridge the two sets of services above so that the browser-mediated techniques of OpenID are used to generate a cryptographic token that is then used to talk to the back-end. But this is really deeply non-trivial! (Not my specialist area, but work with people for whom it is.)


[EDIT]: Of course, if you're just asking about general login methods, then it's trivial. The only one that users really accept is typing their username and password into a webpage, and even then it's only if it is very infrequent. If you're going for this end of things, do remember to only allow logins over HTTPS, that you should only allow the page that they log into the system to be served over HTTPS too, and you'll have to put effort into anti-XSS armoring (a classic SO question!)

Donal Fellows
Well it's actually great that you mentioned both. I had to make this distinction. So yes, I'd like to use both regular user logins from web pages, and API with some form of client authentication.
SODA