Forms AuthWindows Auth – what is more common?

I was talking to some coworkers today about the scenarios for Forms Auth and Windows Auth in line of business applications.    We were having a debate about which was more common.

As you might guess at Microsoft we are an all windows shop, so just about all our line of business applications use Windows auth, and I gotta say it is pretty nice not to have to remember a bunch of user names and passwords.  

But I wonder if that is so common across the industry.. and even for companies that do use Windows Auth, I imagine there are scenarios where Forms auth is still important. 

One place this manifests itself is in the project templates  for things like ASP.NET MVC, ASP.NET WebForms, Silverlight, etc.  Should we be wiring these up to support Forms Auth by default (with a log in\register controls) or Windows Auth where those are not needed?

Here is a little forms auth example… 

 

What do you think?  What is more common in your experience Forms auth or Windows Auth?

Comments

• Anonymous
  June 04, 2009
  Personally i usually use forms auth for almost anything web based.  In ten years I have only used windows auth a handful of time.

• Anonymous
  June 04, 2009
  I've always used forms authentication in my companies.  It's more "webby", so it seems that web developers and architects may be more familiar with it over Windows authentication.  Obviously Windows authentication has plenty of advantages, but if you've got custom user data in your database already, which any application I've worked with does, then it's reasonably trivial to add authentication and basic user management on top of that. I'm not opposed to Windows authentication, just not my first choice.

• Anonymous
  June 04, 2009
  +1 for Forms Auth Echo Bills Moore's comment.

• Anonymous
  June 04, 2009
  I use forms auth for almost everthing which is available from the internet. In intranet scenarios (e.g. in combination with SharePoint) Windows Auth is a great feature.

• Anonymous
  June 04, 2009
  Most of time we a requested to use Forms Auth, often combined with some additional auth Web Service.

• Anonymous
  June 04, 2009
  Forms Auth all the way. OpenId is taking over also, IMO .. but that's using Forms Auth on another server. Never had a use for Windows Auth.

• Anonymous
  June 04, 2009
  The comment has been removed

• Anonymous
  June 04, 2009
  Definitely Forms Auth. But as a web developer I guess that's the norm.

• Anonymous
  June 04, 2009
  The comment has been removed

• Anonymous
  June 04, 2009
  The whole discussion about authentication types becomes more and more moot. Since Microsoft and the rest of the industry is moving towards token based authentication (active & passive), RIA Services and thus SL should directly support Geneva based apps and services and Geneva Server. my 2c Dominick

• Anonymous
  June 04, 2009
  +1 for Windows Auth :) Since we are also all windows in our company, i use Windows Auth for our internal web applications.

• Anonymous
  June 04, 2009
  It always depends on the project and the target group that will use it. In most of the web projects we use Forms Auth, but sometimes even both are needed. With our last Silverlight project we knew that it will be used only within a certain enterprise network so we went with Windows auth, thus not having the users to create new accounts just to use that specific application. Windows auth is my preferred choice when it can be used, but in my practice most of the web applications require Forms auth.

• Anonymous
  June 04, 2009
  I'd have to say Forms Auth (even on desktop apps). I cheer every time we get to use Windows Auth! (I don't know why. Maybe I need help?)

• Anonymous
  June 04, 2009
  I use Windows auth for all my internal web applications targetted for business users.

• Anonymous
  June 04, 2009
  +1 Bill Moore Used form auth dozens of times; but never implemented windows auth. Now, we are shifting toward OpenID though.

• Anonymous
  June 04, 2009
  In all my years of web development I only used forms auth. The fact is that most or a lot of websites are hosted on servers on which the developer or owner of the site doesn't have the level of control needed to create windows users. Forms auth will "just work" wherever the website is deployed.

• Anonymous
  June 04, 2009
  For LOB, Windows Auth is dominant in my experience. I guess most commenters miss that part - and are thinking "open internet" - OpenID has little place in any LOB application I've been part in developing ;-)

• Anonymous
  June 04, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout

• Anonymous
  June 04, 2009
  I think I've only really ever worked with Forms auth. Some of our apps that run in the internet and intranet use Windows internally but Forms externally though. There's lots of talk about us moving to Geneva here though and that could happen pretty soon.

• Anonymous
  June 04, 2009
  Generally we always try to use Windows Authentication for LOB's.  Often I wan't to impersonate the user and therefore I want Windows Auth.  It's just easier to use Windows Auth. Only for really simple apps where there is no need to know a users name or other data would be use Forms Authentication - it's really seldom.

• Anonymous
  June 04, 2009
  I've only ever used Forms Auth :-)

• Anonymous
  June 04, 2009
  I have always used Forms Authentication. In my experience forms authentication gives more control over the rights in a particular domain, may be thats the reason most of the architects are using forms authentication.

• Anonymous
  June 04, 2009
  Forms Auth all the way. because Win Auth is so simple that we don't need to code it :)

• Anonymous
  June 04, 2009
  I use neither. I prefer to use myown auth stuff. It's cleaner, faster and less dependent.

• Anonymous
  June 04, 2009
  you left out one, claims based :)

• Anonymous
  June 04, 2009
  Windows auth for our enterprise apps Forms auth for our public apps

• Anonymous
  June 04, 2009
  We develop enterprise apps mostly using Windows Authentication.

• Anonymous
  June 04, 2009
  Personally i usually use forms auth for almost anything web based application

• Anonymous
  June 04, 2009
  I use a Forms Authentication for all web applications although it would obviously make sense to use Windows Authentication for private or enterprise type   applications where you have your own server, if you run on shared hosting I don't think you are likely to get access to a bunch of windows user accounts.

• Anonymous
  June 04, 2009
  If it's an intranet app, windows auth (where possible) otherwise forms auth.

• Anonymous
  June 04, 2009
  Intranet web based application's we always use Windows Auth - We have > 100 applications. We use a central admin type scenerio to administer roles per application.

• Anonymous
  June 05, 2009
  Both  :) Windows Auth for intranet sites, and I've used Forms Auth (love it) for my internet sites I like that it's included in the templates.

• Anonymous
  June 05, 2009
  I use windows auth whenever possible.  We have several 3rd party apps that have their own authentication system and there is a ton of negative feedback from employees on having to remember 3, 4, 5, etc passwords. When demoing an application I was working on it was noticed that it required authentication to perform some actions (shipping has their role, accounting theirs, etc).  There was a bunch of moaning until I showed them that they never had to 'logon' and that it used their windows account automatically -- they were happy. That said, I am probably going to be working on a public facing vendor portal.  While there are some solutions out there to share form auth and windows auth, it seems wonky (especially for IIS7).  I'll probably end up deploying the application twice -- once public facing with forms auth backed by an SQL Server User Provider and the second for intranet use with windows.  The nice thing about providers is it can be nearly 100% (maybe even 100%) the same code.

• Anonymous
  June 05, 2009
  Windows Auth.  Geneva would be great, but its going to take years for enterprises to get around to installing those types of servers.  How many people here know anything about AD FS, much less are using it (for the right reasons) already? And AD FS is several years old!

• Anonymous
  June 05, 2009
  Definitly forms authentication its easy to use also i don't want to expose internal credentials to web.

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  Forms Auth at a ratio of 10 to 1.

• Anonymous
  June 05, 2009
  Windows auth on intranet and forms auth on internet.

• Anonymous
  June 05, 2009
  I'm for Forms auth... Then one question, is it possible in a winform application to use the Forms auth underlying mecanisms?

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  Windows Auth is completely out of the question for anyone doing a web-based app.  Why would I pay for AD licenses for my customers to log in to my site?   Now, in my 10+ years of web development, the common scenario is that I have "internal" (ie, employees in the office on domain computers) logging into the same web app that my external customers are.  It would be nice to have an "either-or" situation.  We've always just created Form Auth username and passwords for them and they just have to remember both their Windows and web app credentials.

• Anonymous
  June 05, 2009
  Forms should be the default since it works everywhere.  I have used windows auth, but only as an add-on because even in that environment my users want to be able to connect remotely from anywhere.

• Anonymous
  June 05, 2009
  We always try to use Windows authentication when possible, since our campus uses Active Directory for a lot of things anyway, makes it much easier for the users to remember their accounts and passwords.

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  All of our applications use Forms Auth. I would imagine that if you're writing an application for a corporation's use, and you're selling the app to run on their servers, Windows Auth may make more sense (single username system). However, if you're writing apps that you will host yourself and that you sell/license use of the application to customers, then Form Auth is the way to go. My suggestion is to put a question in the ASP.NET Application Wizard for which way to go along with some of the options. ...Matt

• Anonymous
  June 05, 2009
  Personally I prefer form auth. I think it's more flexible in terms of development and extensibility. Windows auth also has a lot of advantages, as both of them have their respective pros and cons. I guess the choice of form/win auth would really depends on the context and the environment the application is utilized. Win auth is more suitable for intranet apps and form auth is probably more familiar and easy to develop for many people creating just ordinary web apps for the general public.

• Anonymous
  June 05, 2009
  In addition, I think there needs to be a mechanism for showing a forms-auth-type username/password form but use Windows auth on the back-end.  This would prove useful for when people are accessing from outside the office.

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  Since the overwhelming number of implimentations will be on publically facing web sites, Forms auth should always be the default and Windows Auth should be an optional setup.  Yes there may be more people using Windows Auth on a day to day basis to login, but not implimentations by a long stretch.

• Anonymous
  June 05, 2009
  As an ISV our products must allow both. Some companies that are AD based want to authenticate/authorized users based on their AD groups, some still want a separate auth system for our app. We still have a large part of customers that run our apps in workgroup environment and don't want to rely on local users/groups.

• Anonymous
  June 05, 2009
  I prefer Windows, not only easy to use and secure, but in case on onsite installation of software it does not require users to remember seprate credentials. Hower, for interner applications there is not option but to use Form authentication

• Anonymous
  June 05, 2009
  The comment has been removed

• Anonymous
  June 05, 2009
  WinAuth only for internal apps All external "web apps" FormsAuth

• Anonymous
  June 05, 2009
  We also use form auth in all of over web applications.

• Anonymous
  June 05, 2009
  We are using Window auth. in our ERP application, Single sign on behaviour is great for user, no need to remember a bunch of passwords

• Anonymous
  June 05, 2009
  My preference is to use Windows Auth because of the reasons you mentioned.  It's simpler.. no passwords to remember. But there are certain situations that require Forms Auth (like shared PCs).  For example, a project I'm currently working on needs to use Forms Auth because the users need to be able to login/logout of the application without having to logout of the PC.  This would be a huge hassle for them. As far as project templates, I think that these should support Forms Auth by default, just because I feel that it's much more common, and more challenging (though not by much) to set up.

• Anonymous
  June 05, 2009
  Let me ask you this Brad, if you were to build a SL app that some of the users are on Mac, how would you do it with Windows authentications? Thanks! ..Ben

• Anonymous
  June 05, 2009
  In any serious enterprise application that I've been involved with, it's always gotten down to Windows (or AD) authentication.  The management of users and privileges is almost always the domain of someone other than the team developing the application and they don't want to built and administrative front-end to manage users and privileges when AD/Windows already does it for you.

• Anonymous
  June 05, 2009
  Hi Brad, Why not both - using dual authentication via extending/implementing the MembershipProvider class. In most cases an extended user data table is needed for such thing as address and other application specific information. A network Guid Id column can be added to this table for the purpose of identifying, adding, removing (or disabling) network users in the forms authentication data store. In an IIS website, for anonymous access, active director is not available. To allow for public access and also provide automated identification for network users, two IIS websites can be created, both pointing to the same virtual path. One of the websites has the anonymous access checkbox checked, the other (for network users) does not. An application timer event can manage scanning the active directory and updating user data store (and user roles table) on a periodic basis. On session start, if System.Security.Principal.SecurityIdentifier UserSID = HttpContext.Current.Request.LogonUserIdentity.User; returns a valid SID then the extended user data table can be queried. If the user is not already authenticated via persistent cookie; automatic login could be triggered to occur via session state variable in a custom page base class. In any event, It’s my opinion that whatever authentication method or data store utilized; it should remain, and be enforced at the presentation layer being completely isolated from any application specific persistence mechanism (ie… MVC and entity frameworks).This general rule will help ensure compatibility across tiers and current/future applications.

• Anonymous
  June 05, 2009
  We have been using ASP.net since the beta days. Almost all our apps use forms auth. Not everyone has a windows domain account. All the applications go through a Single Sign On application (like your Geneva server). >Should we be wiring these up to support Forms Auth by default Absolutely. With support for federated login. Raj Kaimal

• Anonymous
  June 05, 2009
  Windows auth is pretty much never used in our environment. I would like to see basic auth added to ASP.NET. It would come in handy for RIA apps IMHO. I had to create a custom HttpModule to do it and it was a lot more complicated that it should've been.

• Anonymous
  June 05, 2009
  We have an LDAP directory that we use for most authentication. For web apps we use forms auth mostly, but, HTTP basic auth is needed for web services. That is why I would like to see a Basic auth authentication type added to ASP.NET. Microsoft has the tendency to assume that everyone uses all Microsoft and nothing else. Unfortunately to Microsoft's dismay, that is not the real world.

• Anonymous
  June 05, 2009
  Forms authentication is the convenient one.

• Anonymous
  June 05, 2009
  Intranet and Extranet: always Windows authentication Internet only: Forms authentication

• Anonymous
  June 05, 2009
  Forms Auth for a variety of reasons.

• Anonymous
  June 05, 2009
  Definitely Forms Auth... IMHO, with Silverlight becoming a rich platform for business applications this approach will become even more common.

• Anonymous
  June 05, 2009
  Windows Auth is the logical choice for an intranet application - people generally want to log on once to the network and leave it at that. However, it is often still desirable to use Sql Server  for roles rather than relying on Active Directory (which can be a rather blunt instrument for many purposes). So Windows Auth + SqlServerRoleProvider is an important but often overlooked combination.

• Anonymous
  June 05, 2009
  As I see it, Windows Auth works only in an all windows intranet. While many enterprise grade intranet apps are out there, it's not really "web" and definitely not web 2.0+. Asp.net is one of the best tools for "websites" (or web apps - whatever). Most of the users of Asp.net are building websites, not all windows intranet apps. A lot of asp.net sites are hosted on shared hosting and a LOT of beginners don't go all out for dedicated hosting. Having to go through a few complex (for the beginner) steps to enable authentication is definitely not good for someone starting out in Asp.net and touting it against php and other stuff. At the Asp.net forums, we see quite a few devs using their own very simple authentication schemes instead of using the membership API. We also see some more experienced posters support that cause "as a beginner, the membership API is very difficult to set up". They even custom code login / user creation controls instead of levereging the awesome system present in asp.net. Why do we see this? I'd go so far as to say that's because asp.net defaults to windows authentication. Also, people building apps with windows auth (all windows intranet apps) are generally in an enterprise scenario. They're not "beginners" who need hand holding. They're accomplished devs in their own right (who'd hire a beginner to build an enterprise app?). They can easily revert to forms in a matter of a minute. Also, the windows authentication method gives users the convenience to log in to windows and be logged in to the intranet app. Believe it or not, I've had a few clients who don't like this. They explicitly want to be able to log off and login using usernames and passwords. In a couple of apps I did with sensitive info, (both intranet on a windows only network) the client thought that being logged in automatically with windows could be a security concern. [Joe logs in, goes for coffee, Stan sits at the next desk and does stuff from Joes workstation seeing Joe forgot to log off / lock the pc.] So yeah, I definitely think defaulting to forms would help asp.net as a platform.

• Anonymous
  June 05, 2009
  My personal belief is that it should be cardspace/Geneva Server first.  Idealy some way so that people can have "default" cards that they dont care who knows about.  So that you can "autologin" using your windows live ID automaticly to each website you go to (assuming you wanted to you would have to opt-in).  And then gracefully fall back to windows login if that is the only thing avalible, and then fall back to openID form login if nothing else works.  I dont think the tech is quite right yet, esp when it comes to cardspace to do this all correctly, but that would be the ideal.

• Anonymous
  June 05, 2009
  For business apps I use Windows auth. But for more open web applications Forms auth is used.

• Anonymous
  June 06, 2009
  Whenever possible Windows authorization. In all other cases there should be some federated authorization like OpenID or the Geneva framework. I think Microsoft should make more effort to facilitate the developer for internet apps. For example more controls like an 'OpenID selector' or a cardspace control, which integrates easily with windows live and gmail, etc. Make it easy for us!!!

• Anonymous
  June 06, 2009
  There seem to be several realities.  One is that Windows authentication is very good technology for an application that will be deployed in a Windows environment.  A second is that Forms authentication is a very poor technology.  In many web environments, it may be the only viable choice.  But it should not be positioned as a quality technology.  For example, it seems to be relatively common for Microsoft sponsored web sites to have their own local registration and authentication instead of federating with Live ID.  Those cases are a disgrace to the compnay.

• Anonymous
  June 06, 2009
  As many have discussed, we use Windows Authentication for internal-only applications.  This provides the look and feel for 'single sign-on' for those who are logged into enterprise computers. For external applications (public/alternative authentication source), we use forms authentication or (now more commonly) OpenID. The biggest change we're seeing lately is a migration away from Internet Explorer as our primary business apps are working less and less with IE and focusing on FireFox.  As more move away from IE, we will continue to reevaluate our authentication scheme and may be looking more at alternative single sign-on solutions.

• Anonymous
  June 06, 2009
  I have mostly used Windows Authentication, primarily because all of the application users are withing a corporate domain. Our entire company uses Windows clients and active directory, so no Forms authentication required. The question whether using one or the other authentication mechanism is directly tied to the deployment environment, domain infrastructure, intra vs. internet.

• Anonymous
  June 06, 2009
  Working in a Hospital, we have a lot of Generic PC's as clinicians switch PC's all the time, so they do not log on using their AD credentials. So, the applications we build need to use forms authentication.  However, we implemented our own authentication provider which connects to AD to check the credentials. So we are using forms auth, but get the benefit of users only having to remeber one password.

• Anonymous
  June 07, 2009
  The comment has been removed

• Anonymous
  June 07, 2009
  At least three scenarios should be catered for:

1. Forms Auth only
2. Windows Auth only
3. Windows Auth with 'fall-back' to Forms Auth regards

• Anonymous
  June 08, 2009
  Forms Authentication, I've never even seen a chance to use Windows Authentication. Though I'll be frank, I'm not very fond of the default membership system that was introduced in .NET 2.0. It'd be really nice to see it re-hashed as something much more slimline and versatile, instead of relying on clunky keys that we have to jump through hoops to work with.

• Anonymous
  June 08, 2009
  form Authentication. used Windows Auth in past. but most commonly form auth.

• Anonymous
  June 08, 2009
  We use forms auth between our corporate network and the "hosting facilities". IT maintains a strict separation between the two - the live/production Windows domains have no trust relationships or intranet access to the internal LAN. All web authentication is done via forms.

• Anonymous
  June 08, 2009
  The comment has been removed

• Anonymous
  June 08, 2009
  Forms Auth for all the way.  Used Windows Auth years ago, in classic ASP intranet applications, but only Forms Auth in the past 9 years or so.

• Anonymous
  June 10, 2009
  Custom auth.  I'm tied down in more ways than I'm comfortable with already.  I hate to say it, but the less I rely on built-in schemes (that can and do change, sometimes even in a simple service pack), the better off we are.  As far as maintainability goes, anyway.  Oh, and consumer confidence.  =P

• Anonymous
  June 11, 2009
  I want to use both in the same application! We want our internal users to be able to just open the site without having to login. We authenticate them for various applications and roles using internal logic. But, I want the same sites to be available to certain external users as well, using a traditional login/password scenario.

• Anonymous
  June 12, 2009
  Yep - Forms authentication works for me...

• Anonymous
  June 13, 2009
  Forms Authentication for sure!! Windows authentication just isn't worth the effort for anything other than a small Intranet app.

• Anonymous
  June 23, 2009
  I am going to go out on a limb and generalize here.   Large enterprises (that use windows pc's) mostly use windows authentication.  Why - because the volume of help desk calls w/ multiple sign in's goes up exponentially.  So its a cost / simplicity thing.  SSO. Smaller shops or anything externally facing would never use Windows Auth... So its either forms or custom.   As for what you should include in your templates.  Well - that seems like an easy question.  Who are you guys targeting?  Enterprises or web / smaller developers? Answer that and you have an answer to your question.   Then again, this may not be an easy question to answer at all. I think MS has gone back and forth.  For a while ASP.NET 2.0 was all about controls.  Controls like break crumb controls.  I have nothing against bread crumbs, but it seems like a waste of MS talent.  You were surely targeting public web developers. Now things have shifted more to the enterprise again, or at least have balanced out.  I like it. You can guess which side I come from.

• Anonymous
  July 29, 2009
  The comment has been removed

• Anonymous
  August 26, 2009
  メル友募集のあそび場「ラブフリー」はみんなの出逢いを応援する全国版の逆援助コミュニティーです！女の子と真剣にお付き合いしたい方も、複数の女性と戯れたい方も今すぐ無料登録からどうぞ

• Anonymous
  August 27, 2009
  簡単にお小遣い稼ぎをしたい方必見、当サイト逆¥倶楽部では無料登録して女性の性の欲求に応えるだけのアルバイトです。初心者でもすぐに高収入の逆¥交際に興味をもたれた方はTOPページまでどうぞ。

• Anonymous
  August 28, 2009
  プロフ作りました。興味ある方連絡まってま〜す。メアドを乗せておくので連絡ください。色んな人の色んな話聞きたい感じですのでヨロシクhappy-my-life-.-@docomo.ne.jp