Autenticador da Web
Este artigo descreve como você pode usar o .NET Multi-platform App UI (.NET MAUI) a IWebAuthenticator interface. Essa interface permite iniciar fluxos de autenticação baseados em navegador, que escutam um retorno de chamada para uma URL específica registrada no aplicativo.
A implementação padrão da interface está disponível por meio da IWebAuthenticator
WebAuthenticator.Default propriedade. A interface e WebAuthenticator
a IWebAuthenticator
classe estão contidas no Microsoft.Maui.Authentication
namespace.
Visão geral
Muitos aplicativos exigem a adição de autenticação do usuário, e isso geralmente significa permitir que os usuários entrem em suas contas de login existentes da Microsoft, Facebook, Google ou Apple.
Dica
A Microsoft Authentication Library (MSAL) fornece uma excelente solução pronta para adicionar autenticação ao seu aplicativo.
Se você estiver interessado em usar seu próprio serviço Web para autenticação, é possível usar WebAuthenticator para implementar a funcionalidade do lado do cliente.
Por que usar um back-end de servidor
Muitos provedores de autenticação passaram a oferecer apenas fluxos de autenticação explícitos ou bilegados para garantir melhor segurança. Isso significa que você precisará de um segredo do cliente do provedor para concluir o fluxo de autenticação. Infelizmente, os aplicativos móveis não são um ótimo lugar para armazenar segredos e qualquer coisa armazenada no código de um aplicativo móvel, binários ou de outra forma, é considerada insegura.
A prática recomendada aqui é usar um back-end da Web como uma camada intermediária entre seu aplicativo móvel e o provedor de autenticação.
Importante
É altamente recomendável não usar bibliotecas e padrões de autenticação somente para dispositivos móveis mais antigos que não aproveitam um back-end da Web no fluxo de autenticação, devido à sua inerente falta de segurança para armazenar segredos do cliente.
Introdução
Para acessar a funcionalidade, é necessária a seguinte configuração específica da WebAuthenticator plataforma.
O Android requer uma configuração de Filtro de Intenção para lidar com o URI de retorno de chamada. Isso é feito herdando da WebAuthenticatorCallbackActivity classe:
using Android.App;
using Android.Content.PM;
namespace YourNameSpace;
[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)]
[IntentFilter(new[] { Android.Content.Intent.ActionView },
Categories = new[] { Android.Content.Intent.CategoryDefault, Android.Content.Intent.CategoryBrowsable },
DataScheme = CALLBACK_SCHEME)]
public class WebAuthenticationCallbackActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity
{
const string CALLBACK_SCHEME = "myapp";
}
Se a versão do Android de destino do seu projeto estiver definida como Android 11 (R API 30) ou superior, você deverá atualizar o manifesto do Android com consultas que usam os requisitos de visibilidade do pacote do Android.
No arquivo Platforms/Android/AndroidManifest.xml adicione os seguintes queries/intent
nós no manifest
nó:
<queries>
<intent>
<action android:name="android.support.customtabs.action.CustomTabsService" />
</intent>
</queries>
Usando o WebAuthenticator
A API consiste principalmente de um único método, AuthenticateAsync, que usa dois parâmetros:
- A URL usada para iniciar o fluxo do navegador da Web.
- O URI para o qual se espera que o fluxo chame de volta, que é registrado em seu aplicativo.
O resultado é um 'WebAuthenticatorResult, que inclui todos os parâmetros de consulta analisados a partir do URI de retorno de chamada:
try
{
WebAuthenticatorResult authResult = await WebAuthenticator.Default.AuthenticateAsync(
new Uri("https://mysite.com/mobileauth/Microsoft"),
new Uri("myapp://"));
string accessToken = authResult?.AccessToken;
// Do something with the token
}
catch (TaskCanceledException e)
{
// Use stopped auth
}
A WebAuthenticator API se encarrega de iniciar a url no navegador e aguardar até que o retorno de chamada seja recebido:
Se o usuário cancelar o fluxo a qualquer momento, um TaskCanceledException será lançado.
Sessão de autenticação privada
O iOS 13 introduziu uma API de navegador da Web efêmera para que os desenvolvedores iniciem a sessão de autenticação como privada. Isso permite que os desenvolvedores solicitem que nenhum cookie compartilhado ou dados de navegação estejam disponíveis entre as sessões de autenticação e será uma nova sessão de login a cada vez. Isso está disponível por meio do WebAuthenticatorOptions parâmetro passado para o AuthenticateAsync método:
try
{
WebAuthenticatorResult authResult = await WebAuthenticator.Default.AuthenticateAsync(
new WebAuthenticatorOptions()
{
Url = new Uri("https://mysite.com/mobileauth/Microsoft"),
CallbackUrl = new Uri("myapp://"),
PrefersEphemeralWebBrowserSession = true
});
string accessToken = authResult?.AccessToken;
// Do something with the token
}
catch (TaskCanceledException e)
{
// Use stopped auth
}
Diferenças de plataforma
Esta seção descreve as diferenças específicas da plataforma com a API de autenticação da Web.
Guias personalizadas são usadas sempre que disponíveis, caso contrário, o navegador do sistema é usado como fallback.
Iniciar sessão na Apple
De acordo com as diretrizes de revisão da Apple, se o seu aplicativo da Apple usa qualquer serviço de login social para autenticar, ele também deve oferecer o Apple Sign In como uma opção. Para adicionar o Apple Sign In às suas aplicações, terá de adicionar o início de sessão com direito Apple à sua aplicação. Esse direito é definido usando a com.apple.developer.applesignin
chave, do tipo Array
:String
<key>com.apple.developer.applesignin</key>
<array>
<string>Default</string>
</array>
Para obter mais informações, consulte Iniciar sessão com o direito Apple no developer.apple.com.
Para iOS 13 e superior, chame o AppleSignInAuthenticator.AuthenticateAsync método. Isso usa as APIs nativas do Apple Sign In para que seus usuários tenham a melhor experiência possível nesses dispositivos. Por exemplo, você pode escrever seu código compartilhado para usar a API correta em tempo de execução:
var scheme = "..."; // Apple, Microsoft, Google, Facebook, etc.
var authUrlRoot = "https://mysite.com/mobileauth/";
WebAuthenticatorResult result = null;
if (scheme.Equals("Apple")
&& DeviceInfo.Platform == DevicePlatform.iOS
&& DeviceInfo.Version.Major >= 13)
{
// Use Native Apple Sign In API's
result = await AppleSignInAuthenticator.AuthenticateAsync();
}
else
{
// Web Authentication flow
var authUrl = new Uri($"{authUrlRoot}{scheme}");
var callbackUrl = new Uri("myapp://");
result = await WebAuthenticator.Default.AuthenticateAsync(authUrl, callbackUrl);
}
var authToken = string.Empty;
if (result.Properties.TryGetValue("name", out string name) && !string.IsNullOrEmpty(name))
authToken += $"Name: {name}{Environment.NewLine}";
if (result.Properties.TryGetValue("email", out string email) && !string.IsNullOrEmpty(email))
authToken += $"Email: {email}{Environment.NewLine}";
// Note that Apple Sign In has an IdToken and not an AccessToken
authToken += result?.AccessToken ?? result?.IdToken;
Dica
Para dispositivos que não sejam iOS 13, isso iniciará o fluxo de autenticação da Web, que também pode ser usado para habilitar o Apple Sign In em seus dispositivos Android e Windows. Pode iniciar sessão na sua conta do iCloud no simulador do iOS para testar o Apple Sign In.
ASP.NET back-end do servidor núcleo
É possível usar a WebAuthenticator API com qualquer serviço de back-end da Web. Para usá-lo com um aplicativo ASP.NET principal, configure o aplicativo Web com as seguintes etapas:
- Configure seus provedores de autenticação social externos em um aplicativo Web ASP.NET Core.
- Defina o Esquema de Autenticação Padrão como CookieAuthenticationDefaults.AuthenticationScheme em sua
.AddAuthentication()
chamada. - Use
.AddCookie()
em sua chamada .cs.AddAuthentication()
Startup. - Todos os provedores devem ser configurados com
.SaveTokens = true;
o .
services.AddAuthentication(o =>
{
o.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie()
.AddFacebook(fb =>
{
fb.AppId = Configuration["FacebookAppId"];
fb.AppSecret = Configuration["FacebookAppSecret"];
fb.SaveTokens = true;
});
Dica
Se você quiser incluir o Apple Sign In, poderá usar o AspNet.Security.OAuth.Apple
pacote NuGet. Você pode ver o exemplo completo .cs inicialização.
Adicionar um controlador de autenticação móvel personalizado
Com um fluxo de autenticação móvel, você geralmente inicia o fluxo diretamente para um provedor que o usuário escolheu. Por exemplo, clicar em um botão "Microsoft" na tela de entrada do aplicativo. Também é importante retornar informações relevantes para seu aplicativo em um URI de retorno de chamada específico para encerrar o fluxo de autenticação.
Para conseguir isso, use um controlador de API personalizado:
[Route("mobileauth")]
[ApiController]
public class AuthController : ControllerBase
{
const string callbackScheme = "myapp";
[HttpGet("{scheme}")] // eg: Microsoft, Facebook, Apple, etc
public async Task Get([FromRoute]string scheme)
{
// 1. Initiate authentication flow with the scheme (provider)
// 2. When the provider calls back to this URL
// a. Parse out the result
// b. Build the app callback URL
// c. Redirect back to the app
}
}
O objetivo desse controlador é inferir o esquema (provedor) que o aplicativo está solicitando e iniciar o fluxo de autenticação com o provedor social. Quando o provedor chama de volta para o back-end da Web, o controlador analisa o resultado e redireciona para o URI de retorno de chamada do aplicativo com parâmetros.
Às vezes, você pode querer retornar dados, como a volta do provedor access_token
para o aplicativo, o que você pode fazer por meio dos parâmetros de consulta do URI de retorno de chamada. Ou, em vez disso, você pode querer criar sua própria identidade em seu servidor e passar de volta seu próprio token para o aplicativo. O que e como você faz essa parte depende de você!
Confira o exemplo completo do controlador.
Observação
O exemplo acima demonstra como retornar o token de acesso do provedor de autenticação de 3ª parte (ou seja: OAuth). Para obter um token que você pode usar para autorizar solicitações da Web para o próprio back-end da Web, você deve criar seu próprio token em seu aplicativo Web e retorná-lo. A Visão geral da autenticação ASP.NET Core tem mais informações sobre cenários de autenticação avançada no ASP.NET Core.
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de