SQL Serverには2つの認証方式があります。

1. Windows統合認証
2. SQL Server認証

Javaから.NETに移行した開発者の方々は、Windows統合認証に馴染みがないのではないでしょうか。

.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編では以下のように
説明されています。<<以下、書籍から引用>>
-----------------------------------------------------
■Windows統合認証
ASP.NETアプリケーションのワーカープロセスを動作させているWindowsユーザーアカウントを利用して、SQL Serverに接続する方式

■SQL Server認証
SQL Server上に独自に定義されたユーザーアカウント(SQL Serverログインアカウント）
を明示的に指定して、SQL Serverに接続する方式。

------------------------------------------------------

SQL Server認証は、OracleやPostgreSQLに接続する方式と大差ありません。
（接続文字列はDBMSごとに異なりますが。）

Data Source=(local); Initial Catalog=pubs; User Id=sa; Password=pass;

あらかじめデータベース上に定義しておいたユーザー名とパスワードで
データベースに接続しにいきます。

それに比べて、Windows統合認証にはユーザー名やパスワードが必要ありません。

Data Source=(local); Initial Catalog=pubs; Integrated Security=True;

では、どうやってSQL Serverは認証を行うのでしょう。

Webアプリケーションの場合、SQL ServerはASP.NETを動作させているユーザーで認証を行います。タスクマネージャのaspnet_wp.exe、またはw3wp.exeのプロセスのユーザー名がそれにあたります。

Windows統合認証にするメリットは、接続文字列にパスワードが含まれなくなるので、パスワードが盗まれるリスクが少なくなります。
SQL Server認証の場合、接続文字列はデフォルトでapp.configに出力されると思いますが、app.configは多くの開発者が目にするファイルなので、接続文字列を暗号化するか、レジストリなどに移動する必要があります。

ただし、Windows統合認証の場合には、Webサーバー⇔DBサーバーの間に
DB接続ポート以外にWindows統合認証用のポートを空けなければなりません。
また、WebサーバーとDBサーバーを同一のドメインに含めなければなりません。

上記の事項がインフラ上の制約やセキュリティポリシーに違反する場合には、
必然的にSQL Server認証を使うことになるでしょう。

【参考文献】
（書籍）.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編