Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Edit</strong>: </p> <p>It's been several years since I first wrote the answer and the list is getting old. There have been some wide adoption of web-enabled APIs and token-based trust relaying.</p> <p>I haven't read it, but <a href="http://msdn.microsoft.com/en-us/library/ms732362.aspx" rel="nofollow noreferrer">Windows Communication Foundation Security</a> would be a good place to start, if you're looking for something specific to WCF.</p> <p>Also keep your eyes open for what major players like <a href="http://developers.facebook.com/docs/authentication/" rel="nofollow noreferrer">Facebook</a>, <a href="http://code.google.com/apis/accounts/docs/GettingStarted.html" rel="nofollow noreferrer">Google</a>, and <a href="http://dev.twitter.com/pages/auth" rel="nofollow noreferrer">Twitter</a> are doing. They are using open protocols like <a href="http://openid.net/" rel="nofollow noreferrer">OpenID</a> and <a href="http://oauth.net/" rel="nofollow noreferrer">OAuth</a>. At first, OAuth looks complicated, but you should understand the mechanism.</p> <p>In my opinion earlier OAuth reinvents a lot of wheels that SSL has already solved, and leaves some security holes open. An interesting read is <a href="http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/" rel="nofollow noreferrer">Compromising Twitter's OAuth security system</a>. <a href="http://developers.facebook.com/docs/authentication/" rel="nofollow noreferrer">Facebook's OAuth 2.0 implementation</a> and <a href="http://code.google.com/apis/accounts/docs/OAuth2.html" rel="nofollow noreferrer">Google's OAuth 2.0 implementation</a> simplify many of these issues by using https where it makes sense. These are must reads. </p> <p><img src="https://i.stack.imgur.com/HKq4Y.png" alt="enter image description here"></p> <p>The basic concept around OAuth is trust relaying. You would want third-party developers to make apps against your API, but the end users cannot always trust these apps. Giving password to them, is like giving the keys to the kingdom. So the user types in the password into your UI, and your UI redirects to the third party with an access token. </p> <hr> <p><a href="http://msdn.microsoft.com/en-us/library/aa302415.aspx" rel="nofollow noreferrer">Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication</a> is a good introduction to ASP.NET's security models. You can skip over the details because much of the technology is now obsolete.</p> <p>A good overview specific to Web Services is <a href="http://msdn.microsoft.com/en-us/library/aa480545.aspx" rel="nofollow noreferrer">Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0</a>. It says WSE, but basic concepts still remain the same.</p> <p>To get more details on WS-Security, read <a href="http://rads.stackoverflow.com/amzn/click/0672326515" rel="nofollow noreferrer">Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption</a>.</p> <p><a href="http://ecx.images-amazon.com/images/I/51QPQ9QRZQL._SL500_AA240_.jpg" rel="nofollow noreferrer">Securing Web Services with WS-Security http://ecx.images-amazon.com/images/I/51QPQ9QRZQL._SL500_AA240_.jpg</a></p> <p>After reading above, what really helped me was looking at existing implementations like <a href="http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?S3_Authentication.html" rel="nofollow noreferrer">Amazon S3's authentication</a>:</p> <p><a href="http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif" rel="nofollow noreferrer">Amazon S3&#39;s authentication http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif</a></p> <p><a href="http://www.flickr.com/services/api/auth.spec.html" rel="nofollow noreferrer">Flickr Authentication API</a>:</p> <blockquote> <p>Each authentication frob is specific to a user and an application's api key, and can only be used with that key.</p> <p>Authentication frobs are valid for 60 minutes from the time it is created, or until the application calls flickr.auth.getToken, whichever is sooner.</p> <p>Only one authentication frob per application per user will be valid at any one time. Applications must deal with expired and invalid authentication frobs and know how to renew them.</p> </blockquote> <p><a href="http://apiwiki.twitter.com/REST+API+Documentation" rel="nofollow noreferrer">Twitter REST API</a></p> <blockquote> <p>Many Twitter API methods require authentication. All responses are relative to the context of the authenticating user. For example, an attempt to retrieve information on a protected user who is not friends with the requesting user will fail. </p> <p>For the time being, HTTP Basic Authentication is the only supported authentication scheme. When authenticating via Basic Auth, use your registered username or email address as the username component. Session cookies and parameter-based login are known to work but are not officially supported.</p> <p>The OAuth token-based authentication scheme will shortly be offered as an experimental beta release.</p> </blockquote> <p>So it's nice to know the complicated certs and PKI stuff, but the world seems to operate without it just fine.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload