Pular para o conteúdo principal
Para nossos novos amigos:

Logto é uma alternativa ao Auth0 projetada para aplicativos modernos e produtos SaaS. Ele oferece serviços tanto Cloud quanto Open-source para ajudá-lo a lançar rapidamente seu sistema de identidade e gerenciamento (IAM). Desfrute de autenticação, autorização e gerenciamento multi-inquilino tudo em um.

Recomendamos começar com um tenant de desenvolvimento gratuito no Logto Cloud. Isso permite que você explore todos os recursos facilmente.

Neste artigo, vamos percorrer os passos para construir rapidamente a experiência de login SAML (autenticação de usuário) com Flutter e Logto.

Pré-requisitos

Criar um aplicativo no Logto​

Logto é baseado na autenticação OpenID Connect (OIDC) e na autorização OAuth 2.0. Ele suporta o gerenciamento de identidade federada em vários aplicativos, comumente chamado de Autenticação Única (SSO).

Para criar seu aplicativo Native app, basta seguir estas etapas:

  1. Abra o Logto Console. Na seção "Get started", clique no link "View all" para abrir a lista de frameworks de aplicativos. Alternativamente, você pode navegar para Logto Console > Applications e clicar no botão "Create application". Get started
  2. No modal que se abre, clique na seção "Native app" ou filtre todos os frameworks "Native app" disponíveis usando as caixas de seleção de filtro rápido à esquerda. Clique no cartão do framework "Flutter" para começar a criar seu aplicativo. Frameworks
  3. Insira o nome do aplicativo, por exemplo, "Bookstore", e clique em "Create application".

🎉 Ta-da! Você acabou de criar seu primeiro aplicativo no Logto. Você verá uma página de parabéns que inclui um guia de integração detalhado. Siga o guia para ver como será a experiência em seu aplicativo.

Integrar Flutter SDK​

dica:
  • O pacote SDK está disponível no pub.dev e no repositório do Logto no GitHub.
  • O projeto de exemplo é construído usando Flutter material. Você pode encontrá-lo no pub.dev.
  • Este SDK é compatível com aplicativos Flutter nas plataformas iOS, Android e Web. A compatibilidade com outras plataformas não foi testada.

Instalação​

Você pode instalar o logto_dart_sdk package diretamente usando o gerenciador de pacotes pub. Execute o seguinte comando no diretório raiz do seu projeto:

flutter pub add logto_dart_sdk

Ou adicione o seguinte ao seu arquivo pubspec.yaml:

dependencies:
  logto_dart_sdk: ^3.0.0

Em seguida, execute:

flutter pub get

Dependência e configurações​

Compatibilidade de versão do SDK​

Versão do Logto SDKVersão do Dart SDKCompatível com Dart 3.0
< 2.0.0>= 2.17.6 < 3.0.0false
>= 2.0.0 < 3.0.0>= 3.0.0true
>= 3.0.0>= 3.6.0true

Configuração do flutter_secure_storage​

Nos bastidores, este SDK usa flutter_secure_storage para implementar o armazenamento seguro de tokens persistentes em várias plataformas.

  • Keychain é usado para iOS
  • Criptografia AES é usada para Android.

Configurar versão do Android​

Defina o android:minSdkVersion para >= 18 no arquivo android/app/build.gradle do seu projeto.

build.gradle
  android {
      ...

      defaultConfig {
          ...
          minSdkVersion 18
          ...
      }
  }

Desativar backup automático no Android​

Por padrão, o Android faz backup de dados no Google Drive. Isso pode causar a exceção java.security.InvalidKeyException:Failed ao desembrulhar a chave. Para evitar isso,

  1. Para desativar o backup automático, vá para o arquivo de manifesto do seu aplicativo e defina os atributos android:allowBackup e android:fullBackupContent como false.

    AndroidManifest.xml
    <manifest ... >
        ...
        <application
          android:allowBackup="false"
          android:fullBackupContent="false"
          ...
        >
            ...
        </application>
    </manifest>

  2. Exclua sharedprefs do FlutterSecureStorage.

    Se você precisar manter o android:fullBackupContent para seu aplicativo em vez de desativá-lo, pode excluir o diretório sharedprefs do backup. Veja mais detalhes na documentação do Android.

    No seu arquivo AndroidManifest.xml, adicione o atributo android:fullBackupContent ao elemento <application>, conforme mostrado no exemplo a seguir. Este atributo aponta para um arquivo XML que contém regras de backup.

    AndroidManifest.xml
    <application ...
      android:fullBackupContent="@xml/backup_rules">
    </application>

    Crie um arquivo XML chamado @xml/backup_rules no diretório res/xml/. Neste arquivo, adicione regras com os elementos <include> e <exclude>. O exemplo a seguir faz backup de todas as preferências compartilhadas, exceto device.xml:

    @xml/backup_rules
    <?xml version="1.0" encoding="utf-8"?>
    <full-backup-content>
      <exclude domain="sharedpref" path="FlutterSecureStorage"/>
    </full-backup-content>

Por favor, verifique flutter_secure_storage para mais detalhes.

Configuração do flutter_web_auth_2​

Nos bastidores, este SDK usa flutter_web_auth_2 para autenticar usuários com Logto. Este pacote fornece uma maneira simples de autenticar usuários com Logto usando o webview do sistema ou navegador.

Este plugin usa ASWebAuthenticationSession no iOS 12+ e macOS 10.15+, SFAuthenticationSession no iOS 11, Chrome Custom Tabs no Android e abre uma nova janela na Web.

  • iOS: Nenhuma configuração adicional necessária

  • Android: Registre a URL de callback no Android

    Para capturar a URL de callback da página de login do Logto, você precisará registrar seu redirectUri de login no arquivo AndroidManifest.xml.

    AndroidManifest.xml
      <manifest>
        <application>
            <activity
              android:name="com.linusu.flutter_web_auth_2.CallbackActivity"
              android:exported="true">
              <intent-filter android:label="flutter_web_auth_2">
              <action android:name="android.intent.action.VIEW" />
              <category android:name="android.intent.category.DEFAULT" />
              <category android:name="android.intent.category.BROWSABLE" />
              <data android:scheme="YOUR_CALLBACK_URL_SCHEME_HERE" />
              </intent-filter>
            </activity>
        </application>
      </manifest>

  • Navegador Web: Crie um endpoint para lidar com a URL de callback

    Se você estiver usando a plataforma web, precisará criar um endpoint para lidar com a URL de callback e enviá-la de volta para o aplicativo usando a API postMessage.

    callback.html
    <!doctype html>
    <title>Autenticação completa</title>
    <p>
      A autenticação está completa. Se isso não acontecer automaticamente, por favor, feche a janela.
    </p>
    <script>
      function postAuthenticationMessage() {
        const message = {
          'flutter-web-auth-2': window.location.href,
        };

        if (window.opener) {
          window.opener.postMessage(message, window.location.origin);
          window.close();
        } else if (window.parent && window.parent !== window) {
          window.parent.postMessage(message, window.location.origin);
        } else {
          localStorage.setItem('flutter-web-auth-2', window.location.href);
          window.close();
        }
      }

      postAuthenticationMessage();
    </script>

Por favor, verifique o guia de configuração no pacote flutter_web_auth_2 para mais detalhes.

Integração​

Inicializar LogtoClient​

Importe o pacote logto_dart_sdk e inicialize a instância LogtoClient na raiz do seu aplicativo.

lib/main.dart
import 'package:logto_dart_sdk/logto_dart_sdk.dart';
import 'package:http/http.dart' as http;

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'Logto Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  late LogtoClient logtoClient;

  void render() {
    // mudança de estado
  }

  // LogtoConfig
  final logtoConfig = const LogtoConfig(
    endpoint: "<your-logto-endpoint>",
    appId: "<your-app-id>"
  );

  void _init() {
    logtoClient = LogtoClient(
      config: logtoConfig,
      httpClient: http.Client(), // Cliente HTTP opcional
    );
    render();
  }

  @override
  void initState() {
    super.initState();
    _init();
  }

  // ...
}

Implementar login​

Antes de mergulharmos nos detalhes, aqui está uma visão geral rápida da experiência do usuário final. O processo de login pode ser simplificado da seguinte forma:

  1. Seu aplicativo invoca o método de login.
  2. O usuário é redirecionado para a página de login do Logto. Para aplicativos nativos, o navegador do sistema é aberto.
  3. O usuário faz login e é redirecionado de volta para o seu aplicativo (configurado como o URI de redirecionamento).

Sobre o login baseado em redirecionamento​

  1. Este processo de autenticação segue o protocolo OpenID Connect (OIDC), e o Logto aplica medidas de segurança rigorosas para proteger o login do usuário.
  2. Se você tiver vários aplicativos, pode usar o mesmo provedor de identidade (Logto). Uma vez que o usuário faz login em um aplicativo, o Logto completará automaticamente o processo de login quando o usuário acessar outro aplicativo.

Para saber mais sobre a lógica e os benefícios do login baseado em redirecionamento, veja Experiência de login do Logto explicada.

Antes de começar, você precisa adicionar um URI de redirecionamento no Admin Console para o seu aplicativo.

Vamos mudar para a página de detalhes do Aplicativo no Logto Console. Adicione um URI de redirecionamento io.logto://callback e clique em "Salvar alterações".

URI de redirecionamento no Logto Console
  • Para iOS, o esquema de URI de redirecionamento não importa realmente, pois a classe ASWebAuthenticationSession ouvirá o URI de redirecionamento independentemente de estar registrado.
  • Para Android, o esquema de URI de redirecionamento deve ser registrado no arquivo AndroidManifest.xml.

Após configurar o URI de redirecionamento, adicionamos um botão de login à sua página, que chamará a API logtoClient.signIn para invocar o fluxo de login do Logto:

lib/main.dart
class _MyHomePageState extends State<MyHomePage> {
  // ...
  final redirectUri = 'io.logto://callback';

  @override
  Widget build(BuildContext context) {
    // ...

    Widget signInButton = TextButton(
      onPressed: () async {
        await logtoClient.signIn(redirectUri);
        render();
      },
      child: const Text('Sign In'),
    );

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            signInButton,
          ],
        ),
      ),
    );
  }
}

Implementar logout​

Vamos mudar para a página de detalhes do Aplicativo no Logto Console. Adicione um URI de Redirecionamento Pós-Logout io.logto://callback e clique em "Salvar alterações".

URI de Redirecionamento Pós-Logout no Logto Console

URI de Redirecionamento Pós-Logout é um conceito do OAuth 2.0 que implica o local para onde deve redirecionar após o logout.

Agora vamos adicionar um botão de logout na página principal para que os usuários possam sair do seu aplicativo.

lib/main.dart
class _MyHomePageState extends State<MyHomePage> {
  // ...

  final postSignOutRedirectUri = 'io.logto//home';

  @override
  Widget build(BuildContext context) {
    // ...

    Widget signOutButton = TextButton(
      onPressed: () async {
        await logtoClient.signOut(postSignOutRedirectUri);
        render();
      },
      child: const Text('Sign Out'),
    );

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            signInButton,
            signOutButton,
          ],
        ),
      ),
    );
  }
}

Lidar com o status de autenticação​

O Logto SDK fornece um método assíncrono para verificar o status de autenticação. O método é logtoClient.isAuthenticated. O método retorna um valor booleano, true se o usuário estiver autenticado, caso contrário, false.

No exemplo, renderizamos condicionalmente os botões de login e logout com base no status de autenticação. Agora vamos atualizar o método render em nosso Widget para lidar com a mudança de estado:

lib/main.dart
class _MyHomePageState extends State<MyHomePage> {
  // ...
  bool? isAuthenticated = false;

  void render() {
    setState(() async {
      isAuthenticated = await logtoClient.isAuthenticated;
    });
  }

  @override
  Widget build(BuildContext context) {
    // ...

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            isAuthenticated == true ? signOutButton : signInButton,
          ],
        ),
      ),
    );
  }
}

Ponto de verificação: Teste seu aplicativo​

Agora, você pode testar seu aplicativo:

  1. Execute seu aplicativo, você verá o botão de login.
  2. Clique no botão de login, o SDK iniciará o processo de login e redirecionará você para a página de login do Logto.
  3. Após fazer login, você será redirecionado de volta para seu aplicativo e verá o botão de logout.
  4. Clique no botão de logout para limpar o armazenamento de tokens e sair.

Adicionar conector SAML​

Para habilitar um login rápido e melhorar a conversão de usuários, conecte-se com Flutter como um provedor de identidade (IdP). O conector social do Logto ajuda você a estabelecer essa conexão em minutos, permitindo a entrada de vários parâmetros.

Para adicionar um conector social, basta seguir estas etapas:

  1. Navegue até Console > Connectors > Social Connectors.
  2. Clique em "Add social connector" e selecione "SAML".
  3. Siga o guia README e complete os campos obrigatórios e personalize as configurações.

Aba do conector

nota:

Se você estiver seguindo o guia do Conector no local, pode pular a próxima seção.

Configurar Aplicativo SAML padrão​

Criar conta de IdP social e registrar aplicativo SAML (IdP)​

Vamos passar pelas configurações do conector SAML.

Antes de começarmos, você pode ir a um provedor de identidade social que suporte o protocolo SAML e criar sua própria conta. Okta, OneLogin, Salesforce e algumas outras plataformas suportam autenticação baseada no protocolo SAML.

Se o seu IdP exigir a criptografia da asserção SAML e o recebimento de solicitações de autenticação assinadas, você deve gerar sua chave privada e o certificado correspondente usando o algoritmo RSA. Mantenha a chave privada para uso do seu SP e carregue o certificado no IdP.

Você também precisa configurar a URL do ACS (Assertion Consumer Service) como ${your_logto_origin}/api/authn/saml/${connector_id} para lidar com a asserção SAML do IdP. Você pode encontrar seu connectorId na página de detalhes do conector SAML no Console de Administração do Logto.

nota:

De acordo com o design atual do Logto, só suportamos Redirect-binding para enviar solicitações de autenticação e POST-binding para receber asserções SAML. Embora isso possa não parecer legal, acreditamos que o design atual pode lidar com a maioria dos seus casos de uso. Se você tiver algum problema, sinta-se à vontade para entrar em contato!

Configurar conector SAML (SP)​

Nesta seção, vamos apresentar cada atributo em detalhe.

entityID Obrigatório​

entityID (ou seja, issuer) é o identificador da Entidade. Ele é usado para identificar sua entidade (entidade SP SAML) e corresponder à equivalência em cada solicitação/resposta SAML.

signInEndpoint Obrigatório​

O endpoint do IdP para o qual você envia solicitações de autenticação SAML. Normalmente, você pode encontrar esse valor na página de detalhes do IdP (ou seja, SSO URL ou Login URL do IdP).

x509Certificate Obrigatório​

O certificado x509 gerado a partir da chave privada do IdP, espera-se que o IdP tenha esse valor disponível.

O conteúdo do certificado vem com o cabeçalho -----BEGIN CERTIFICATE----- e o final -----END CERTIFICATE-----.

idpMetadataXml Obrigatório​

O campo é usado para colocar conteúdos do arquivo XML de metadados do seu IdP.

nota:

O analisador XML que estamos usando não suporta namespace personalizado. Se os metadados do IdP vierem com namespace, você deve removê-los manualmente. Para namespace de arquivo XML, veja referência.

assertionConsumerServiceUrl Obrigatório​

A URL do serviço consumidor de asserção (ACS) é o endpoint do SP para receber solicitações POST de asserção SAML do IdP. Como mencionamos na parte anterior, geralmente é configurado nas configurações do IdP, mas alguns IdPs obtêm esse valor das solicitações de autenticação SAML, por isso também adicionamos esse valor como um campo OBRIGATÓRIO. Seu valor deve ser semelhante a ${your_logto_origin}/api/authn/saml/${connector_id}.

signAuthnRequest​

O valor booleano que controla se a solicitação de autenticação SAML deve ser assinada, cujo valor padrão é false.

encryptAssertion​

encryptAssertion é um valor booleano que indica se o IdP irá criptografar a asserção SAML, com valor padrão false.

nota:

Os atributos signAuthnRequest e encryptAssertion devem estar alinhados com os parâmetros correspondentes da configuração do IdP, caso contrário, um erro será lançado para mostrar que a configuração não corresponde. Todas as respostas SAML precisam ser assinadas.

requestSignatureAlgorithm​

Isso deve estar alinhado com os algoritmos de assinatura do IdP para que o Logto possa verificar a assinatura da asserção SAML. Seu valor deve ser http://www.w3.org/2000/09/xmldsig#rsa-sha1, http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 ou http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 e o valor padrão é http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

messageSigningOrder​

messageSigningOrder indica a ordem de assinatura e criptografia do IdP, seu valor deve ser sign-then-encrypt ou encrypt-then-sign e o valor padrão é sign-then-encrypt.

privateKey e privateKeyPass​

privateKey é um valor OPCIONAL e é necessário quando signAuthnRequest é true.

privateKeyPass é a senha que você definiu ao criar privateKey, necessária quando necessário.

Se signAuthnRequest for true, o certificado correspondente gerado a partir de privateKey é necessário pelo IdP para verificar a assinatura.

encPrivateKey e encPrivateKeyPass​

encPrivateKey é um valor OPCIONAL e é necessário quando encryptAssertion é true.

encPrivateKeyPass é a senha que você definiu ao criar encPrivateKey, necessária quando necessário.

Se encryptAssertion for true, o certificado correspondente gerado a partir de encPrivateKey é necessário pelo IdP para criptografar a asserção SAML.

nota:

Para geração de chaves e certificados, openssl é uma ferramenta maravilhosa. Aqui está uma linha de comando de exemplo que pode ser útil:

openssl genrsa -passout pass:${privateKeyPassword} -out ${encryptPrivateKeyFilename}.pem 4096
openssl req -new -x509 -key ${encryptPrivateKeyFilename}.pem -out ${encryptionCertificateFilename}.cer -days 3650

Os arquivos privateKey e encPrivateKey são obrigados a serem codificados no esquema pkcs1 como string pem, o que significa que os arquivos de chave privada devem começar com -----BEGIN RSA PRIVATE KEY----- e terminar com -----END RSA PRIVATE KEY-----.

nameIDFormat​

nameIDFormat é um atributo OPCIONAL que declara o formato do nome id que responderia. O valor pode estar entre urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, urn:oasis:names:tc:SAML:2.0:nameid-format:persistent e urn:oasis:names:tc:SAML:2.0:nameid-format:transient, e o valor padrão é urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified.

timeout​

timeout é a tolerância de tempo para validação de tempo, já que o tempo entre sua entidade SP e a entidade IdP pode ser diferente e a conexão de rede também pode trazer algum atraso. A unidade é em milissegundos, e o valor padrão é 5000 (ou seja, 5s).

profileMap​

Logto também fornece um campo profileMap que os usuários podem personalizar o mapeamento dos perfis dos fornecedores sociais, que geralmente não são padrão. Cada chave profileMap é o nome do campo de perfil de usuário padrão do Logto e o valor correspondente deve ser o nome do campo de perfil social. No estágio atual, o Logto só se preocupa com 'id', 'name', 'avatar', 'email' e 'phone' do perfil social, apenas 'id' é OBRIGATÓRIO e os outros são campos opcionais.

Tipos de configuração​

NomeTipoObrigatórioValor Padrão
signInEndpointstringtrue
x509certificatestringtrue
idpMetadataXmlstringtrue
entityIDstringtrue
assertionConsumerServiceUrlstringtrue
messageSigningOrderencrypt-then-sign | sign-then-encryptfalsesign-then-encrypt
requestSignatureAlgorithmhttp://www.w3.org/2000/09/xmldsig#rsa-sha1 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512falsehttp://www.w3.org/2001/04/xmldsig-more#rsa-sha256
signAuthnRequestbooleanfalsefalse
encryptAssertionbooleanfalsefalse
privateKeystringfalse
privateKeyPassstringfalse
nameIDFormaturn:oasis:names:tc:SAML:1.1:nameid-format:unspecified | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress | urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent | urn:oasis:names:tc:SAML:2.0:nameid-format:transientfalseurn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
timeoutnumberfalse5000
profileMapProfileMapfalse
Campos do ProfileMapTipoObrigatórioValor Padrão
idstringfalseid
namestringfalsename
avatarstringfalseavatar
emailstringfalseemail
phonestringfalsephone

Referência​

Salvar sua configuração​

Verifique se você preencheu os valores necessários na área de configuração do conector Logto. Clique em "Salvar e Concluído" (ou "Salvar alterações") e o conector SAML deve estar disponível agora.

Ativar conector SAML na Experiência de Login​

Depois de criar um conector social com sucesso, você pode habilitá-lo como um botão "Continuar com SAML" na Experiência de Login.

  1. Navegue até Console > Experiência de login > Inscrição e login.
  2. (Opcional) Escolha "Não aplicável" para o identificador de inscrição se você precisar apenas de login social.
  3. Adicione o conector SAML configurado à seção "Login social".

Aba Experiência de Login

Teste e Validação​

Retorne ao seu aplicativo Flutter. Agora você deve conseguir fazer login com SAML. Aproveite!

Leituras adicionais​

Fluxos de usuário final: Logto fornece fluxos de autenticação prontos para uso, incluindo MFA e SSO corporativo, juntamente com APIs poderosas para implementação flexível de configurações de conta, verificação de segurança e experiência multi-inquilino.

Autorização (Authorization): A autorização define as ações que um usuário pode realizar ou os recursos que ele pode acessar após ser autenticado. Explore como proteger sua API para aplicativos nativos e de página única e implementar Controle de Acesso Baseado em Papel (RBAC).

Organizações (Organizations): Particularmente eficaz em aplicativos SaaS multi-inquilino e B2B, o recurso de organização permite a criação de inquilinos, gerenciamento de membros, RBAC em nível de organização e provisionamento just-in-time.

Série IAM do cliente: Nossos posts em série sobre Gerenciamento de Identidade e Acesso do Cliente (ou Consumidor), do básico ao avançado e além.