API Web ASP.NET

API Web ASP.NET segura com o AD do Windows Azure e os componentes do Microsoft OWIN

Vittorio Bertocci

À medida que a função da API Web se torna mais proeminente, também aumenta a necessidade de garantir que você a use confidencialmente em cenários de alto valor, onde dados e operações confidenciais podem ser expostos.

O setor está claramente convergindo para uma solução que proteja as APIs REST que dependem do padrão OAuth 2.0. No entanto, na prática, não há diretrizes detalhadas sobre o que fazer em nível de projeto. Além disso, as classes e as ferramentas existentes no Microsoft .NET Framework para proteger as comunicações foram criadas para funcionar com tipos de aplicativos específicos (aplicativos Web UX baseados em postback). Eles não são uma boa opção para APIs Web e os cenários de vários clientes que as APIs habilitam. Como resultado, a proteção de uma API Web tem sido uma atividade bastante artesanal. Ela não é necessariamente insegura, mas varia muito entre soluções e requer grande quantidade de código personalizado.

Com a liberação do Visual Studio 2013, você pode deixar tudo isso para trás. Essa edição introduz ferramentas inovadoras do ASP.NET e middleware de segurança dos componentes do Microsoft Open Web Interface para .NET (OWIN) que simplificam a proteção da API Web As novas ferramentas e modelos do ASP.NET permitem configurar um projeto API Web para terceirizar diretamente a autenticação para o Active Directory (AD) do Windows Azure, emitindo o código necessário no projeto local e nas entradas correspondentes no AD do Windows Azure.

Neste artigo, mostrarei como tirar proveito desses novos recursos do Visual Studio 2013 para criar uma API Web simples protegida pelo AD do Windows Azure. Também mostrarei como criar um cliente de teste para que você possa ver a API em ação. Também explicarei rapidamente o que acontece nos bastidores, o que poderá servir como um ponto de partida se você desejar se aprofundar e explorar mais os aspectos avançados desse cenário.

Credenciais, por favor

A autenticação se resume em solicitar a um chamador, ao enviar uma mensagem a um servidor, para incluir algum tipo de credencial que possa verificar sua identidade ou recuperar seus atributos. O servidor usa essas informações para autorização, determinando se o acesso deve ser concedido e em quais condições.

Os recursos normalmente descarregam a maior parte das funções de autenticação em um provedor de serviços externo, comumente conhecido como uma autoridade ou um provedor de identidades. Esses provedores se encarregam das tarefas pesadas, como da integração de novos usuários, da atribuição de credenciais, do manuseio dos fluxos de ciclo de vida (como recuperação de senhas), fornecimento de uma interface do usuário para a autenticação do usuário, verificação das credenciais por meio de vários protocolos, gerenciamento de fatores de autenticação múltipla, detecção de fraudes e muito mais.

Com essas funções fora do caminho, a única tarefa de autenticação restante é verificar se a autenticação foi bem-sucedida na autoridade de sua preferência. Tipicamente, isso envolve a verificação de um token de segurança, um fragmento de dados emitido por uma autoridade para um chamador quando a autenticação é bem-sucedida.

Normalmente, os tokens de segurança são criados de acordo com um formato específico, assinados digitalmente por uma chave que identificará de maneira inequívoca a autoridade emitente e contêm alguns dados que vinculam exclusivamente o token ao recurso de destino. Quando o recurso recebe uma solicitação, ele procura pelo token que a acompanha. Se for encontrado um token que atenda aos atributos de validação requeridos, o chamador será autenticado.

Nesse nível de detalhes, o padrão é tão genérico que pode descrever muitas abordagens diferentes da autenticação. Vou aplicar o padrão a esse cenário atribuindo as funções de alto nível a entidades concretas.

O recurso O recurso será o projeto API Web 2 do ASP.NET que preciso proteger. Você pode aplicar os requisitos de autenticação com granularidade mais fina. Por exemplo, você pode definir um subconjunto de ações a serem protegidas e deixar que outras aceitem chamadores anônimos.

A autoridade Configurarei a API Web para descarregar suas necessidades de autenticação no AD do Windows Azure AD, uma PaaS (plataforma como serviço) disponível para todos os assinantes do Windows Azure. O AD do Windows Azure foi especificamente desenvolvido para oferecer suporte a cargas de trabalho de aplicativos na nuvem. O serviço armazena informações sobre usuários (atributos e credenciais) e estrutura organizacional. Você pode sincronizar seus dados com o Active Directory de seu Windows Server, se preferir, ou viver exclusivamente na nuvem sem a necessidade de uma infraestrutura no local.

Quase todos os serviços online da Microsoft (Office 365, Intune e Windows Azure) tiram proveito do AD do Windows Azure para suas necessidades de autenticação e diretório. Graças aos padrões abertos e ao suporte para protocolos comuns, você pode se conectar ao AD do Windows Azure de virtualmente qualquer aplicativo (UX Web, API Web, cliente nativo, servidor para servidor e assim por diante) e qualquer plataforma. Demonstrarei como registrar seus aplicativos no AD do Windows Azure e tirar proveito de seus pontos de extremidade do OAuth 2.0.

Formato e validação de token A especificação do OAuth 2.0 não exige nenhum formato de token específico, mas o formato JWT (JSON Web Token) (bit.ly/14EhlE8) para cenários REST se tornou o padrão na prática. O AD do Windows Azure e os componentes do Microsoft OWIN oferecem suporte ao formato JWT em fluxos do OAuth 2.0. Menciono isso principalmente para fornecer algum contexto. A mecânica da aquisição e da validação do JWT é realizada pelo middleware, e o formato do token é transparente para o código do aplicativo.

O cliente Quando um recurso conta com uma autoridade para tratar a autenticação, ela é efetivamente desacoplada do cliente. Como o usuário (e o aplicativo cliente) obtém um token se torna uma questão entre o usuário e a autoridade. Isso é ótimo para a capacidade de manutenção do código, mas se você quiser ver sua API em ação, ainda precisará configurar um cliente. Você saberá como registrar um cliente nativo para a API Web no AD do Windows Azure, e como usar a ADAL (AD Authentication Library) do Windows Azure para permitir que um aplicativo cliente .NET rico autentique usuários no AD do Windows Azure e obtenha tokens para chamadas seguras para a API Web.

A Figura 1 mostra os vários elementos da solução que criarei. Não se preocupe se você não compreender alguns dos rótulos neste ponto: Tudo será introduzido à medida que eu explicar o desenvolvimento da solução.

Figura 1 A arquitetura da solução completa

Criando o projeto da API Web

Para criar o projeto da API Web, use as novas ferramentas e os modelos do ASP.NET no Visual Studio 2013. Abra o Visual Studio e crie um novo projeto de Aplicativo Web ASP.NET. Na caixa de diálogo do novo projeto, selecione o modelo Web API. Clique no botão Change Authentication. 

Serão apresentados os estilos de autenticação que você pode escolher na caixa para uma API Web, conforme mostrado na Figura 2. Escolha Organizational Accounts, que permite que você use o AD do Windows Azure como a autoridade. Para obter mais informações sobre todas as opções, consulte bit.ly/1bhWngl. A meta aqui é coletar informações sobre as características de sua API Web que são importantes de uma perspectiva de gerenciamento de identidades e determinar qual instância do AD do Windows Azure (normalmente conhecida como “tenant”) você deve configurar para manipular a autenticação

Figura 2 A caixa de diálogo de autenticação Organizational Accounts

O primeiro menu suspenso determina se apenas um locatário do AD do Windows Azure (típico de um aplicativo de linha de negócios) ou vários locatários do AD do Windows Azure (como se espera de um aplicativo SaaS [software como serviço] devem usar o aplicativo. Normalmente você selecionará Single Organization, se seu aplicativo for usado por funcionários de sua empresa, ou Multiple Organizations, se o aplicativo for acessado por usuários de muitas empresas. Dito isso, essas duas alternativas estão disponíveis atualmente apenas para WebForms ASP.NET e aplicativos ASP.NET MVC. Atualmente, o modelo de projeto API Web oferece suporte apenas à opção Single Organization.

A caixa de texto Domain identifica qual locatário do AD do Windows Azure deve registrar seu aplicativo. Tipicamente, é o diretório empresarial associado à assinatura do Windows Azure, mas qualquer diretório para o qual você tenha credenciais administrativas funcionará (mais informações a respeito mais tarde). Na hora da criação, todo locatário do AD do Windows Azure tem um domínio de três níveis associado no formato yourorganization.onmicrosoft.com. Geralmente, você associará o locatário a um ou mais domínios que você já possui. No exemplo da Figura 2, uso meu próprio domínio, cloudidentity.net.

O menu suspenso Access Level especifica quais direitos de acesso o aplicativo deve ter no diretório. O valor padrão, Single Sign On, permite que o diretório emita tokens para seu aplicativo. Esse é um simples reconhecimento de que o aplicativo está registrado. A autoridade não emitirá tokens para aplicativos não registrados, mesmo quando a autenticação for bem-sucedida.

Outros níveis de acesso incluem “Read directory data” e “Read and write directory data” que, respectivamente, permitem que o aplicativo consulte o diretório e modifique seu conteúdo. Isso é feito por meio de Graph API, uma interface programática baseada no REST criada para permitir que aplicativos de qualquer plataforma com uma de pilha HTTP ganhem acesso delegado ao diretório. Ficarei com o nível de acesso Single Sign On padrão e não demonstrarei a Graph no projeto da API Web. Que é, no entanto, um recurso extremamente poderoso do AD do Windows Azure. Para obter mais informações sobre a Graph API do AD do Windows Azure, consulte bit.ly/1aByRLS.

Depois de inserir o domínio associado a seu locatário do AD do Windows Azure, clique em OK para gerar o projeto. A ferramenta executará duas tarefas:

1. Acessarei o locatário do AD do Windows Azure selecionado e adicionarei uma entrada descrevendo o aplicativo que está sendo criado.
2. Emitirei código para um projeto da API Web, adicionarei o middleware de segurança necessário dos componentes do Microsoft OWIN para manipular a autenticação do AD do Windows Azure e gerar o código de inicialização necessário para validar tokens de entrada de acordo com o locatário preferencial do AD do Windows Azure.

A primeira tarefa é executada pela Graph API (o próprio Visual Studio é um cliente da Graph API). Para adicionar a entrada que descreve o aplicativo que você está criando ao diretório, é necessário obter um token do diretório que comprove que você tem os privilégios necessários para gravar no diretório. É por isso que, quando você clica em OK, o Visual Studio apresenta o prompt de autenticação que você vê na Figura 3.

Figura 3 Entrada da conta no prompt de autenticação

Tudo o que você precisa fazer é digitar as credenciais de administrador do diretório. A ferramenta verifica se você tem os privilégios necessários para executar as operações necessárias. Quando você clica em OK, o Visual Studio entra em contanto com o AD do Windows Azure e cria os arquivos do projeto.

Agora você tem uma API Web totalmente configurada, pronta para impor que apenas chamadores do locatário do AD do Windows Azure especificado ganhem acesso. Vamos examinar melhor.

Vá para o painel Solution Explorer onde, na raiz, você verá um arquivo chamado Startup.cs. Se você leu o artigo "Introdução ao projeto Katana" da edição do mês passado (msdn.microsoft.com/magazine/dn451439), você já saberá que a classe nesse arquivo é chamada na inicialização do aplicativo. Neste caso, a implementação é simples:

public partial class Startup
{
  public void Configuration(IAppBuilder app)
  {
    ConfigureAuth(app);
  }
}

Como é padrão, você espera encontrar o método ConfigureAuth em alguma classe sob a pasta App_Start da solução. Na verdade trata-se do arquivo Startup.Auth.cs. Esta é a aparência do arquivo:

public partial class Startup
{
  public void ConfigureAuth(IAppBuilder app)
  {
    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
      new WindowsAzureActiveDirectoryBearerAuthenticationOptions
      {
        Audience = ConfigurationManager.AppSettings["ida:Audience"],
        Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
      });
  }
}

A convenção de nomenclatura app.Use* sugere que o método adicione uma implementação de middleware ao pipeline do OWIN. Nesse caso, o middleware adicionado inspeciona a solicitação recebida para ver se a Autorização do cabeçalho HTTP contém um token de segurança. É assim que você protege uma solicitação de acordo com a especificação do token portador do OAuth 2.0 (consulte bit.ly/W4OqA3). Se um token for encontrado, ele será validado por meio de várias verificações padrão: O token foi emitido pela autoridade pretendida? Ele foi violado em trânsito? Está expirado?

Se o token parecer bom, o middleware projeta seu conteúdo em uma entidade de segurança, atribui a entidade de segurança ao usuário atual e cede o controle ao próximo elemento no pipeline. Se o token não passar nas verificações, o middleware envia o código de erro apropriado de volta.

Se não houver nenhum token, o middleware simplesmente permite que a chamada passe sem criar uma entidade de segurança. A lógica da autorização, tipicamente na forma de filtros de autorização, usa a presença ou a ausência de uma entidade principal (e de seu conteúdo) para decidir se a solicitação deve se atendida ou o acesso negado.

O único parâmetro passado para o middleware, WindowsAzureActiveDirectoryBearerAuthenticationOptions, fornece as configurações para determinar a validade de um token. Ele captura os valores brutos durante a criação do projeto e os armazena no arquivo web.config. O valor de Audience é o identificador pelo qual a API Web é conhecida para o AD do Windows Azure. Quaisquer tokens que contenham um Audience diferente são destinados a outros recurso e devem ser rejeitados.

A propriedade Tenant indica o locatário do AD do Windows Azure usado para terceirizar a autenticação. O middleware usa essas informações para acessar o locatário e ler todas as outras propriedades (como qual chave deve ser usada para verificar as assinaturas do token) que determinam a validade de um token.

As poucas linhas de código geradas automaticamente são tudo o que é necessário para autenticar chamadores com o AD do Windows Azure. A única coisa restante a fazer no projeto da API Web é decorar com [Autorizar} os métodos que você deseja proteger. Adicione isso a todos os métodos em ValuesController. Para simplificar, estou trabalhando com os controladores padrão fornecidos com o modelo.

Agora, como você verifica se a API Web se comporta como planejado? A maneira mais simples é criar um cliente de teste.

Registrar um cliente nativo

Da mesma forma como o AD do Windows não emitirá tokens para APIs Web que não foram registradas, o Windows Azure requer que todos os clientes que solicitem tokens também sejam registrados. Para obter um token para uma API Web específica, um cliente registrado também deve receber explicitamente acesso àquela API Web no AD do Windows Azure. Essas configurações de tempo de design devem estar implementadas antes de qualquer usuário tentar a autenticação. Agora, mostrarei como usar o portal do Windows Azure para registrar um aplicativo cliente e criar a permissão que o vincula à API Web que você criou.

Comece acessando o portal do Windows Azure. Vou autenticar com a mesma conta que usei anteriormente. Para economizar tempo, navegarei diretamente para o portal do Windows Azure de meu locatário do AD do Windows Azure. Você obtém essa URL adicionando seu domínio de locatário ao endereço normal do portal, em meu caso, https://manage.windowsazure.com/cloudidentity.net.

A navegação para a URL específica do locatário é mais rápida do que buscar a caixa “Sign in with your organizational account” na página de logon geral. Observe que se o AD do Windows Azure com o qual você está trabalhando não for um administrador ou coadministrador de sua assinatura do Windows Azure, você desejará entrar no portal usando suas credenciais normais (uma conta da Microsoft ou outra entidade organizacional).

Quando o portal for carregado, selecione o ícone do Active Directory na lista de serviços disponíveis, clique em seu diretório e, em seguida, na guia Applications. Você verá uma lista de todos os aplicativos criados, incluindo a entrada do novo projeto da API Web. Para criar uma nova entrada, clique no botão Add na barra de comandos na parte inferior da página. Você verá a caixa de diálogo mostrada na Figura 4. Tecnicamente, você pode definir qualquer tipo de aplicativo e esse será um cliente válido para sua API Web. Escolha um aplicativo cliente nativo e mova para a próxima tela.

Figura 4 A primeira etapa do Add Application Wizard no portal do Active Directory do Windows Azure

A próxima e última tela pede que você insira uma URI de redirecionamento para o aplicativo. Essa URI é simplesmente um identificador usado durante o fluxo da aquisição do token do OAuth 2.0 para sinalizar para o chamador que a parte interativa do processo de autenticação terminou. O restante do processo de aquisição de token prosseguirá sem entrada do usuário. Dependendo da plataforma na qual você desenvolve o cliente nativo, você pode precisar lidar com diferentes restrições. Por exemplo, um aplicativo da Windows Store exigirá que você use o esquema do protocolo ms-app:// se você usar determinados recursos (consulte os detalhes em bit.ly/13KrM6i).

Nesse caso, escreverei um aplicativo de área de trabalho .NET clássico, que é muito complacente. Qualquer URI válida funcionará. Usei https://cloud­identity.net/myWebAPItestclient para garantir que me lembrarei de para que esse cliente é.

Assim que eu finalizar a entrada do aplicativo, verei a página mostrada na Figura 5.

Figura 5 A página de início rápido

A seção Update Your Code fornece informações das quais você precisará ao escrever o aplicativo cliente. Isso inclui as configurações da URI de redirecionamento e a ID do cliente (um identificador simples) de que você precisa ao criar uma solicitação de token para a autoridade.

A seção Configure Access to Web APIs oferece um link para a área do portal onde você pode especificar a API à qual o cliente deve ter acesso. Se você seguir o link, acessará a página de propriedades do aplicativo mostrada na Figura 6. Na parte inferior, você verá um menu suspenso que permite especificar a API Web que você deseja que seu cliente acesse. Observe que o menu suspenso lista os aplicativos que você definiu e as APIs internas, especificamente a Graph API do AD do Windows Azure.

Figura 6 A página Properties do aplicativo cliente nativo no portal do Active Directory do Windows Azure

Escolha a entrada do projeto da API Web e clique em Save. Com isso, tudo estará pronto no AD do Windows Azure para que um cliente obtenha tokens para seu serviço. Deixe o navegador aberto naquela página, pois você precisará de alguns dos dados que serão exibidos.

Criando um projeto cliente simples e testando a API Web

Finalmente, você está pronto para criar um cliente de teste e experimentar a API Web autenticada. Você pode criar qualquer tipo de cliente, em qualquer plataforma que ofereça uma pilha HTTP. Para simplificar a tarefa de obtenção e manutenção de tokens, a Microsoft fornece a ADAL, que facilita a autenticação no Active Directory (no Windows Azure e no Windows Server) sem precisar se tornar um especialista em protocolos de autenticação.

A biblioteca do Microsoft .NET Framework foi liberada e está em Developer Preview para a Windows Store. Para obter um tutorial sobre como implementar esse cenário com um aplicativo da Windows Store, consulte bit.ly/17YtYVg.) Eventualmente, haverá versões direcionadas a todas as principais plataformas de cliente.

Como a versão do .NET já está disponível para o público geral, eu a usarei aqui. Além das diferenças sintáticas entre diferentes pilhas, o que você aprenderá aqui será prontamente aplicável a outras plataformas e tipos de aplicativos. Se você não puder esperar, lembre-se de que todas as comunicações no cenário descrito aqui seguem padrões abertos e são documentadas em detalhes. Você pode codificar a lógica de solicitação de token muito facilmente. Para obter um exemplo que usa o Windows Phone 8, consulte bit.ly/YatATk.

O projeto é para um novo aplicativo WPF (Windows Presentation Foundation) dentro da mesma solução, mas você pode escolher qualquer tipo de projeto usado para execução interativa com um usuário. Depois de criar o projeto, adicionarei um botão e um manipulador de eventos de cliques para disparar a lógica de invocação da API Web.

A ADAL é distribuída como um pacote NuGet. Para adicioná-lo ao projeto cliente, basta abrir o Package Manager Console no menu Tools no Visual Studio e digitar Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 1.0.0. Agora, adicione o código da Figura 7 no manipulador de eventos de cliques.

Figura 7 Código a ser adicionado ao manipulador de eventos de cliques

private async void btnCall_Click(object sender, RoutedEventArgs e)
{
  // Get token
  AuthenticationContext ac = new AuthenticationContext(
    "https://login.windows.net/cloudidentity.net");
  AuthenticationResult ar =
    ac.AcquireToken("https://cloudidentity.net/WindowsAzureADWebAPITest",
    "a4836f83-0f69-48ed-aa2b-88d0aed69652",
    new Uri("https://cloudidentity.net/myWebAPItestclient"));
  // Call Web API
  string authHeader = ar.CreateAuthorizationHeader();
  HttpClient client = new HttpClient();
  HttpRequestMessage request = new HttpRequestMessage(
    HttpMethod.Get, "https://localhost:44353/api/Values");
  request.Headers.TryAddWithoutValidation("Authorization", authHeader);
  HttpResponseMessage response = await client.SendAsync(request);
  string responseString = await response.Content.ReadAsStringAsync();
  MessageBox.Show(responseString);
}

Não se preocupe se o código parecer intimidante. Tudo ficará claro em um minuto.

A primeira linha inicializa um novo AuthenticationContext. No código do aplicativo, uma instância de AuthenticationContext representa a autoridade com a qual trabalhar. Neste caso, a autoridade é meu locatário do AD do Windows Azure representado pela URI https://login.windows.net/\[mydomain\]. Você usaria a mesma lógica para conectar-se a um diretório no local passando o endereço de seu servidor AD FS (Serviços de Federação do Active Directory). Consulte bit.ly/1d553F0 para obter detalhes.

A segunda linha solicita um token do AuthenticationContext. Há muitas maneiras de criar uma solicitação de token, todo cenário e tipo de aplicativo chama parâmetros diferentes. Neste caso, desejo especificar que o recurso para o qual desejo um token é minha API Web. Portanto, passo o identificador de sua entrada no AD do Windows Azure. Esse é o mesmo valor usado como a audiência no projeto da API Web. Em seguida, como é o cliente nativo que está solicitando o token, preciso passar a ID do cliente e a URI de redirecionamento de meu cliente da página de configuração do aplicativo que deixei aberta no navegador.

Isso é tudo o que preciso para obter um token. O restante do código coloca esse token no cabeçalho HTTP correto de acordo com a especificação OAuth 2.0 e executa a chamada real.

Agora, experimente a solução. Depois de alterar a solução para iniciar todos os projetos de uma vez, pressione a F5. Assim que a execução atingir a chamada para AcquireToken, a caixa de diálogo da autenticação será aberta conforme mostrado na Figura 8. A ADAL faz o contato com o ponto de extremidade correto e renderiza a experiência de autenticação fornecida pelo servidor em uma caixa de diálogo pop-up sem exigir que você escreva nenhum código da interface do usuário.

Figura 8 A caixa de diálogo de autenticação da biblioteca de autenticação do Active Directory

Quando eu forneço as credenciais de qualquer usuário válido de meu locatário do diretório, obtenho um token de volta. O código subsequente apresenta o token para a API Web nos cabeçalhos da solicitação. O middleware de segurança o valida. Como todos os parâmetros de validação são uma correspondência, o código de status HTTP 200 é retornado com os resultados, concluindo com êxito a comprovação de conceito deste cenário.

Por diversão, clique no botão novamente. Desta vez, você verá que o token é retornado imediatamente, sem um prompt. Isso ocorre porque a ADAL tem um cache de tokens interno que mantém o registro dos tokens. Ele até tem o cuidado de atualizar silenciosamente os tokens expirados sempre que possível.

Próximos passos

Eu mal arranhei a superfície do que você pode realizar com a API Web, os componentes do Microsoft OWIN, o AD do Windows Azure e a ADAL. Os tokens emitidos pelo AD do Windows Azure não são simplesmente comprovações de autenticação. Eles contêm informações ricas sobre os usuários que você pode acessar facilmente na entidade de segurança do usuário e usar para lógica sofisticada de autorização. O processo de autenticação pode ir muito além do nome do usuário e da senha mostrados aqui.

De vários fatores de autenticação a logon único direto em cenários federados, as possibilidades são infindáveis. A integração com a Graph API pode dar acesso a você a uma infinidade de recursos. Você pode consultar o diretório para obter informações que vão além do usuário autenticado no momento, da simples funcionalidade de seletor de pessoas ao rastreamento avançado da estrutura organizacional.

Esses recursos podem aumentar a funcionalidade de APIs Web baseadas na nuvem. Até agora, você precisou executá-las no local por trás do firewall corporativo. Você também pode usar código semelhante com o Active Directory do Windows Server em um dos exemplos mais claros da simetria de recursos na nuvem e no local.

Naturalmente, você também pode publicar a API Web no Windows Azure sem alterar uma única linha de código, os recursos de autenticação continuarão funcionando. A única coisa que você precisa alterar está no projeto cliente. A URL do serviço será alterada de acordo com o novo local do aplicativo. No entanto, a lógica de aquisição de um token pode permanecer exatamente igual porque o identificador do recurso não precisa estar vinculado ao endereço físico do recurso.

Vittorio Bertocci é gerente de programa chefe na equipe do AD do Windows Azure, onde cuida da experiência do desenvolvedor. Bertocci é muito conhecido na comunidade de desenvolvedores por suas atividades de divulgação há uma década sobre identidade e desenvolvimento através de seus livros, suas sessões em conferências importantes, seu blog (cloudidentity.com) e feed do Twitter (twitter.com/vibronet).

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Howard Dierking e Daniel Roth
Howard Dierking é gerente de programa na equipe de estruturas e ferramentas do Windows Azure onde seu foco está em ASP.NET, NuGet e APIs Web. Anteriormente, Dierking trabalhou como editor-chefe da MSDN Magazine e também comandou o programa de certificação de desenvolvedores para o Microsoft Learning. Antes de fazer parte da Microsoft, ele foi desenvolvedor e arquiteto de aplicativos por dez anos, com foco em sistemas distribuídos.

Daniel Roth é gerente de programa sênior na equipe da Plataforma de Aplicativos do Windows Azure, que trabalha atualmente na API Web ASP.NET. Antes de trabalhar no ASP.NET, ele trabalhou no WCF, começando quando contribuiu pela primeira vez com o .NET Framework 3.0. Suas paixões incluem agradar os clientes criando estruturas simples e fáceis de usar.