Passive is good!

Pam Lahoud

Here’s a quick read from Premier Developer consultant Marius Rochon’s blog.  In it, Marius gives some great reasons to leverage passive authentication protocols in your applications rather than writing your own code to handle credentials.

Some time back I wrote about avoiding handling of credentials (creation/maintenance/verification of user names, passwords, pins, etc.) in your own application code, but rather delegating that functionality to a specialized, external identity provider (IdP; http://blogs.msdn.com/b/mrochon/archive/2014/12/02/should-an-application-handle-user-credentials.aspx). This aversion should apply to even collection of credentials (e.g. asking the user for user name/password). Even that role should be delegated to the IdP via the use of the correct, passive authentication protocol. Here are my reasons why: 

1. Allows the application to get out of the business of challenging the user for credentials and then handling these credentials. Reduces chances that rogue or careless programmer allows these credentials to leak out to an attacker.
2. Allows the identity provider to change the strength or method of the authentication challenge (username/password vs certificate, multi-factor) without any change to the application
3. Provides for federation of identities from other identity providers with no change to the application.
4. Allows for single-sign on to multiple applications
5. Allows for the identity provider and the application to not have a direct line communication (since it can happen only via browser redirection) – for example, you may want the identity provider to be inside a firewalled perimeter.
6. Offloads credential verification, usually the first step in the interaction between an external party and your application to a dedicated system, thus providing a way to mitigate denial of service attacks. Before the attacker gets to call your application, the attacker has to get through authentication and get an access token. Compared to the cost of responding to the challenge with credentials, obtaining a token and then calling your application, the cost of validating the token is relatively low thus making it easier for your application to avoid being swamped by spurious requests. Furthermore, some server proxies will completely screen off requests with invalid tokens or throttle number of calls with same access token (assuming they all come from one attacker using single credentials to flood your system with requests). For example, Azure API Management has a policy which allows you to set a limit on the number of requests with same http header or url query string value (see: https://msdn.microsoft.com/en-us/library/azure/dn910913.aspx).

Pam Lahoud

Follow