Estou usando o seguinte código em um site MVC5:

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel loginModel) {
    if (ModelState.IsValid) {
        var authenticated = FormsAuthentication.Authenticate(loginModel.UserName, loginModel.Password);
        if (authenticated) {
            FormsAuthentication.SetAuthCookie(loginModel.UserName, true);
            return RedirectToAction("AdminPanel");
        }
        ModelState.AddModelError("", "The username and password combination were incorrect");
    }
    return View(loginModel);
}

Que lança o seguinte aviso:

System.Web.Security.FormsAuthentication.Authenticate (string, string) 'está obsoleto:' A alternativa recomendada é usar as APIs de associação, como Membership.ValidateUser. Para mais informações, vejahttp://go.microsoft.com/fwlink/?LinkId=252463. '

Primeiro um aviso - sou um daqueles desenvolvedores que gosta de manter-se atualizado com as coisas e prefiro evitar avisos no VS completamente. No entanto, neste exemplo em particular, estou usando autenticação extremamente primitiva, que vem diretamente do web.config, da seguinte maneira:

<authentication mode="Forms">
    <forms loginUrl="~/account/login" timeout="2880" slidingExpiration="true" name=".ASPXFORMSAUTH">
        <credentials passwordFormat="SHA1">
            <user name="MyUserName" password="a-big-long-password-hash"/>
        </credentials>
    </forms>
</authentication>

Não há absolutamente nenhum requisito adicional de login neste projeto - o uso de um banco de dados é um exagero e não há necessidade de login distribuído; basicamente, armazenar os detalhes no web.config é a solução mais ideal e provavelmente haverá apenas um usuário por aplicativo. Sem dúvida tirarei o código de autenticação do controlador (usando DI / IoC), mas ainda pretendo usar o objeto FormsAuthentication para autenticar nos detalhes em web.config.

Embora eu esteja plenamente ciente dos provedores de associação, DotNetOpenAuth e o novo (mas bastante horrível imo) modelo de autenticação baseado em OWIN, o código acima é mais do que adequado.

Primeira pergunta - Por que o FormsAuthentication se tornou obsoleto quando este é um caso de uso perfeitamente válido? Eu entendo que o FormsAuthentication é uma caixa preta selada, é difícil de testar e o código por trás dele é específico do domínio, mas nesse caso específico (onde quero ler detalhes diretamente da seção do web.config), parece loucura escrever um provedor de associação ou um serviço de autenticação personalizado?

Segunda pergunta - A menos que esteja faltando alguma coisa, o novo modelo OWIN é para autenticação distribuída e não é adequado para um sistema de segurança de nível empresarial baseado em função. Das muitas postagens de blog, white papers e SO que li, também parece que ainda está incompleta. Estou certo em minhas suposições? OWIN é o futuro de todos os sistemas de segurança ou devo continuar escrevendo sistemas de segurança sob medida mais adequados às necessidades de meus clientes?