Sign In With Apple na prática

Vamos entender como funciona e como influencia na sua privacidade?

João Gabriel
Accenture Digital Product Dev
8 min readMar 15, 2021

--

A Apple sempre demonstrou preocupação com a privacidade dos seus usuários. Na WWDC de 2019, isso ficou ainda mais evidente com o lançamento do Sign in with Apple, ou seja, uma forma de fazer login com as suas informações da Apple. Neste post, vamos entender como isso funciona e como podemos implementar a função em nossos apps seguindo as boas práticas indicadas pela Apple. Bora lá? 😃🍎

Do que estamos falando?

O Sign in With Apple é um mecanismo que permite ao usuário acessar seu app com apenas alguns passos e ainda manter preservada sua privacidade durante toda a experiência. A ideia é usar o Apple ID do usuário e as informações já contidas nele, de acordo com a necessidade do app para realizar o sign in.

Quando requisitado sobre suas informações, o usuário pode optar por ocultar seu email, o que é possível graças a uma identificação indireta ao email do usuário. Para isso, um email único é gerado pela Apple e funciona como intermediário de comunicação entre o app e o e-mail verdadeiro do usuário. Além de conveniente e seguro, isso garante que o seu app esteja recebendo um e-mail verificado previamente pela Apple. Interessante, né? 😃

Aplicativo com botão de Sign in with Apple.

Implementando

E como usar essa inovação? O passo a passo abaixo vai te guiar na implementação do Sign in with Apple no teu app iOS.

Configurando o projeto
Antes de tudo, é necessário uma conta de desenvolvedor para poder ativar a funcionalidade de sign in. Tendo uma conta adicionada ao seu projeto, vá até as configurações do projeto, na aba em Signing & Capabilities, clique em + Capability e pesquise por Sign in with Apple para adicionar ao seu projeto.

Adicionando Sign In With Apple na aba de Signing & Capabilities.

Botão de Sign in with Apple
Podemos implementar o componente de interface padrão para Sign in with Apple usando UIKit ou SwiftUI. Neste tutorial, vamos usar o UIKit.

Dica: utilizando o componente padrão da Apple, o texto do botão já é traduzido automaticamente para a língua do device.

Boa prática: é válido lembrar que a Apple recomenda evitar que o usuário necessite efetuar um scroll na tela para ver o botão de sign in. Além disso, é recomendado que o botão da Apple seja configurado com o mesmo tamanho dos botões das outras formas de sign in.

Então vamos colocar a mão na ̶m̶a̶s̶s̶a̶ código. 👨🏻‍💻

Botão usando UIKit
Primeiro, é preciso importar o AuthenticationServices para usar na UIView em que o botão será implementado:

A implementação do botão padrão em UIKit utiliza o componente ASAuthorizationAppleIDButton, e pode ser feita da seguinte forma:

Dica: o botão de sign in pode ser implementado com diferentes aparências, dependendo da interface do seu app. Pode ficar com fundo branco, branco com borda ou preto. Caso queira se aprofundar mais sobre as possíveis aparências do botão, acesse o Human Interface Guidelines.

Para poder realizar uma injeção de dependência dentro do módulo de autenticação que estiver criando, sugiro implementar um manager. Nesse caso podemos criar o SignInWithAppleManager, que vai conter a lógica de sign in de fato. Quando o usuário clica no botão, a nossa UIViewController vai chamar o método actionButtonSignIn: que aciona o signIn do manager (vamos ver a implementação em breve).

A implementação do SignInWithAppleManager, onde acontece de fato o sign in, fica assim:

Em relação à implementação do SignInWithAppleManager, temos o seguinte:

  • Linha 1 = mais uma vez é necessário importar o AuthenticationServices para utilizar o Sign in with Apple.
  • Linha 30 = o método signIn cria um ASAuthorizationAppleIDProvider que é utilizado para criar uma requisição utilizando o método createRequest:.
  • Linha 32 = o objeto de request possui uma lista de informações que serão requisitadas ao usuário, no caso a variável requestedScopes. Neste exemplo estamos solicitando o nome completo e o email do usuário.
  • Linha 34 = para realizar de fato o request e fazer o menu do Sign in with Apple aparecer na tela, é necessário criar um ASAuthorizationController passando como parâmetro os requests desejados e acionar o método performRequests:.

Apesar da semelhança com o método signIn:, o método signInWithExistingAccountFlows: lida com o caso de autenticação em que o usuário já tem previamente um login e senha cadastrados em seu iCloud Keychain para esse app. Esse método pode ser chamado no viewDidAppear:animated: da UIViewController do seu módulo de sign in.

A classe responsável pelo sign in deve conformar com o protocolo ASAuthorizationControllerDelegate para poder lidar com os casos de sucesso e falha do sign in. Neste exemplo, o SignInWithAppleManager é conformado ao protocolo e adicionado como delegate do ASAuthorizationController (linha 35). Esse protocolo é implementado como mostra o exemplo abaixo:

Implementação do delegate ASAuthorizationControllerDelegate.

O ASAuthorizationControllerDelegate obriga a implementação do caso de sucesso e falha do sign in. Esse delegate implementa o método de sucesso authorizationController:didCompleteWithAuthorization:, e este método de sucesso, na primeira vez em que o sign in é realizado para um usuário (apenas na primeira vez), o objeto authorization (ASAuthorization) retorna contendo os dados do usuário na propriedade credential (linhas 6 e 7).

Neste caso, é esperado que sua aplicação salve essas informações conforme necessário, no seu serviço de back-end, por exemplo, e no keychain, que vai facilitar ainda mais um futuro sign in do usuário. Uma recomendação é que no primeiro sign in seja feito um cache dessas informações como nome e e-mail (que são disponibilizadas apenas no primeiro sign in). Assim, em caso de ter algum problema de comunicação com seu back-end, as informações podem ser enviadas posteriormente.

No authorizationController:didCompleteWithAuthorization: podemos notar outro case para a credential do tipo ASPasswordCredential, que por sua vez corresponde ao login do usuário que já tinha informações de cadastro no seu iCloud Keychain. Neste caso, podemos autenticar usando o email já cadastrado no Keychain.

Apresentando a UI do Sign in with Apple

O protocolo ASAuthorizationControllerPresentationContextProviding possui o método obrigatório presentationAnchor(for:), que nos obriga a retornar a UIWindow. No caso, essa deve ser a UI na qual será apresentada a UI padrão de confirmação do Sign in with Apple. Este protocolo deve ser implementado caso seja necessário apresentar a UI em outra UIWindow que não seja a principal.

Lidando com mudanças de estado

Na classe SignInWithAppleManager podemos adicionar o método verifySignIn:userIdentifier: para lidar com possíveis situações que podem ocorrer após o login do usuário. Da seguinte forma:

Antes de chamar esse método, é necessário ter um userIdentifier. Se o mesmo não foi cadastrado no keychain podemos direcionar o usuário para o fluxo de autenticação. Se for possível acessar o userIdentifier, podemos fazer a validação com o método. Neste caso passamos por parâmetro, então, o userIdentifier que foi gerado no momento em que o usuário fez sign in no app e permite identificar se o usuário encerrou a sessão ou se ainda não existem credenciais de sign in configuradas. Utilizando o ASAuthorizationAppleIDProvider podemos verificar o estado da autenticação do usuário com o método getCredentialState:forUserID:. Os possíveis estados do credential state são os seguintes:

  • authorized (quando o usuário está autorizado),
  • notFound (usuário não encontrado)
  • revoked (autorização do usuário foi revogada).

Essa verificação de estado é bem rápida e pode ser feita logo na inicialização do app. Em todos os casos, podemos chamar o método signInStatus:active: do SignInWithAppleManagerDelegate, que é implementado pela Controller responsável pelo manager, passando a situação do login.

Além disso, podemos implementar um observer para o caso da autenticação do usuário ser revogada durante a execução do app, dessa forma:

Assim, caso a autenticação seja revogada, podemos guiar o usuário novamente para o fluxo de sign in.

E é isso! Se você seguiu o tutorial até agora, está com tudo o que precisa para implementar o Sign In With Apple no seu app, podendo passar o SignInWithAppleManager por injeção de dependência para a sua controller de sign in. Abaixo seguem algumas informações importantes 😉

Dicas da Apple

Seguindo o Human Interface Guidelines, podemos notar alguns pontos relevantes antes de implementar um login em seu app:

  • Considere utilizar o Sign In With Apple em todas as versões do seu app e site para criar uma experiência consistente para o usuário.
  • Tente adiar ao máximo o momento de requisitar o login do usuário, pois ele tende a abandonar o app quando é forçado a efetuar login antes de fazer algo de útil no app. Permita que o usuário se familiarize com o app antes de requisitar um login.
  • Explique as vantagens e benefícios de efetuar login no app.
  • Não peça uma senha. A vantagem do Sign in with Apple é justamente não ter que memorizar senhas, então não peça, a menos que o usuário pare de usar o Sign in with Apple.

Atenção às Guidelines

Ainda é pertinente lembrar que de acordo com a App Store Review Guidelines, no item 4.8 Sign in with Apple, se o app permite a criação de uma conta primária do usuário com serviços de autenticação de terceiros (como Facebook, Google, Twitter, LinkedIn, Amazon, ou WeChat) é obrigatória a implementação do Sign in with Apple como uma opção equivalente.

Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.

Além disso vale a pena lembrar que é obrigatória a implementação do Sign in with Apple se seu app utiliza apenas o seu próprio sistema de sign in, se o app é educacional ou para empresas que precisam de um sign in com uma conta existente de enterprise, se o app usa um sistema do governo ou indústria para identificação ou id eletrônico ou se o app é cliente de serviço de terceiro e necessita usar um sign in para o email, rede social ou conta de terceiro direto do conteúdo deles.

  • Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.

Conclusão

Seguindo apenas alguns passos podemos tornar a experiencia do usuário mais simples e, assim, poder facilitar uma das etapas mais burocráticas dentro de um app, o sign in. Essa solução da Apple é muito conveniente pois respeita a privacidade do usuário final, podendo ocultar seu email caso escolhido e ao mesmo tempo fazendo com que o usuário ganhe tempo para interagir de fato com o seu app.

Algumas referências

Se você quiser aprender ainda mais com uma comunidade gigante de desenvolvedores iOS aqui na Concrete, é só dar uma olhada aqui e cadastrar o seu currículo. E se tiver alguma dúvida ou sugestão é só deixar um comentário ou me procurar no Github ou no LinkedIn. Até a próxima!

--

--