Escolhendo um m\u00e9todo\/fornecedor de autentica\u00e7\u00e3o<\/h2>\n
Existem basicamente 1.000 maneiras de criar autentica\u00e7\u00e3o em seu aplicativo. Em vez de nos concentrarmos em provedores espec\u00edficos (assunto para outro artigo no blog), vamos analisar os tipos de solu\u00e7\u00f5es de autentica\u00e7\u00e3o<\/strong> e alguns exemplos de cada uma. Em termos de implementa\u00e7\u00e3o, o next-auth<\/a> est\u00e1 se tornando rapidamente uma op\u00e7\u00e3o popular para integrar seu aplicativo Next.js a v\u00e1rios provedores, adicionar SSO, etc.<\/p>\n Este m\u00e9todo \u00e9 t\u00e3o simples quanto parece: voc\u00ea armazena nomes de usu\u00e1rio e senhas em um banco de dados relacional. Quando um usu\u00e1rio se cadastra pela primeira vez, voc\u00ea insere uma nova linha na tabela A autentica\u00e7\u00e3o tradicional com banco de dados \u00e9 certamente o esquema de autentica\u00e7\u00e3o mais popular, considerando a totalidade dos aplicativos existentes e existe basicamente desde sempre. \u00c9 altamente flex\u00edvel, econ\u00f4mica e n\u00e3o te prende a nenhum fornecedor espec\u00edfico. Mas voc\u00ea precisa constru\u00ed-la voc\u00ea mesmo e, em particular, se preocupar com a criptografia e garantir que essas preciosas senhas n\u00e3o caiam em m\u00e3os erradas.<\/p>\n Nos \u00faltimos anos (e, para cr\u00e9dito do Firebase, h\u00e1 mais de alguns anos), tornou-se relativamente padr\u00e3o para os provedores de bancos de dados gerenciados oferecer algum tipo de solu\u00e7\u00e3o de autentica\u00e7\u00e3o gerenciada. O Firebase<\/a>, o Supabase<\/a> e o AWS<\/a> oferecem banco de dados gerenciado e autentica\u00e7\u00e3o gerenciada como servi\u00e7o por meio de um conjunto de APIs que abstrai facilmente a cria\u00e7\u00e3o de usu\u00e1rios e o gerenciamento de sess\u00f5es (falaremos mais sobre isso adiante).<\/p>\n Para conectar um usu\u00e1rio com a autentica\u00e7\u00e3o do Supabase, voc\u00ea s\u00f3 precisa fazer<\/a> o seguinte:<\/p>\n Talvez at\u00e9 mais comum do que a autentica\u00e7\u00e3o como um servi\u00e7o do seu DBaaS (Database as a Service) seja a autentica\u00e7\u00e3o como um servi\u00e7o como uma empresa ou produto inteiro. Auth0<\/a>, que existe desde 2013 (agora propriedade da Okta), e adi\u00e7\u00f5es recentes como Stytch<\/a> t\u00eam priorizado a experi\u00eancia do desenvolvedor e ganhado uma certa relev\u00e2ncia no mercado.<\/p>\n O SSO permite que voc\u00ea “terceirize” sua identidade para um provedor externo, que pode variar desde um fornecedor focado em seguran\u00e7a empresarial como a Okta<\/a> at\u00e9 algo mais amplamente adotado como o Google<\/a> ou o GitHub. O SSO do Google \u00e9 onipresente no mundo do SaaS, e algumas ferramentas voltadas para desenvolvedores autenticam apenas via GitHub.<\/p>\n Seja qual for o provedor que voc\u00ea escolher, o SSO geralmente \u00e9 um complemento para os outros tipos de autentica\u00e7\u00e3o acima e tem suas pr\u00f3prias idiossincrasias<\/a> em rela\u00e7\u00e3o \u00e0 integra\u00e7\u00e3o com plataformas externas (aten\u00e7\u00e3o: o SAML usa XML).<\/p>\n N\u00e3o h\u00e1 uma escolha “correta” aqui – o que \u00e9 certo para o seu projeto depende de suas prioridades. Se voc\u00ea quiser fazer as coisas andarem rapidamente sem muita configura\u00e7\u00e3o inicial, terceirizar a autentica\u00e7\u00e3o faz sentido (at\u00e9 mesmo terceiriz\u00e1-la completamente, inclusive a interface do usu\u00e1rio, para algu\u00e9m como a Auth0). Se voc\u00ea prev\u00ea uma configura\u00e7\u00e3o mais complexa, faz sentido criar seu pr\u00f3prio backend de autentica\u00e7\u00e3o. E se voc\u00ea pretende dar suporte a clientes maiores, precisar\u00e1 adicionar o SSO em algum momento.<\/p>\n O Next.js \u00e9 t\u00e3o popular neste momento que a maioria desses provedores de autentica\u00e7\u00e3o tem documentos e guias de integra\u00e7\u00e3o espec\u00edficos para o Next.js.<\/p>\n Alguns provedores de autentica\u00e7\u00e3o, como Auth0, na verdade, fornecem p\u00e1ginas web hospedadas inteiras para cadastro e login. Mas se voc\u00ea est\u00e1 construindo essas p\u00e1ginas do zero, eu acho \u00fatil cri\u00e1-las no in\u00edcio do processo, j\u00e1 que voc\u00ea precisar\u00e1 delas para fornecer como redirecionamentos quando realmente implementar sua autentica\u00e7\u00e3o.<\/p>\n Portanto, faz sentido criar a estrutura para essas p\u00e1ginas e, depois, adicionar as solicita\u00e7\u00f5es ao backend posteriormente. A maneira mais direta de implementar a autentica\u00e7\u00e3o \u00e9 ter duas dessas rotas:<\/p>\n Al\u00e9m do b\u00e1sico, voc\u00ea precisar\u00e1 cobrir casos extremos, como quando um usu\u00e1rio esquece a senha. Algumas equipes preferem ter o processo de redefini\u00e7\u00e3o de senha em uma rota separada, enquanto outras adicionam elementos din\u00e2micos de interface do usu\u00e1rio (UI) \u00e0 p\u00e1gina regular de login.<\/p>\n Uma boa p\u00e1gina de inscri\u00e7\u00e3o pode n\u00e3o significar a diferen\u00e7a entre o sucesso e o fracasso, mas pequenos toques podem deixar uma boa impress\u00e3o e, em geral, proporcionar uma experi\u00eancia do usu\u00e1rio melhor. Aqui est\u00e3o alguns exemplos de sites da web que deram um toque especial aos seus processos de autentica\u00e7\u00e3o.<\/p>\n O call to action na barra de navega\u00e7\u00e3o da Stripe muda com base em se voc\u00ea tem uma sess\u00e3o autenticada ou n\u00e3o. Veja como fica o site de marketing se voc\u00ea n\u00e3o estiver autenticado. Observe o call to action para fazer login:<\/p>\n E aqui est\u00e1 a apar\u00eancia se voc\u00ea estiver autenticado. Observe que o Call to Action muda para levar o usu\u00e1rio ao painel de controle em vez de fazer login:<\/p>\n Isso n\u00e3o muda fundamentalmente minha experi\u00eancia com o Stripe, mas \u00e9 bom.<\/p>\n Uma observa\u00e7\u00e3o t\u00e9cnica interessante: h\u00e1 um bom motivo para que a maioria das empresas n\u00e3o fa\u00e7a com que a barra de navega\u00e7\u00e3o em seu site de marketing “dependa” da autentica\u00e7\u00e3o – isso significaria uma solicita\u00e7\u00e3o de API extra para verificar o estado autenticado em cada carregamento de p\u00e1gina, a maioria dos quais s\u00e3o para visitantes que provavelmente n\u00e3o s\u00e3o.<\/p>\n Nos \u00faltimos anos, especialmente em SaaS, as empresas come\u00e7aram a adicionar conte\u00fado \u00e0 p\u00e1gina de inscri\u00e7\u00e3o para “incentivar” o usu\u00e1rio a realmente concluir a inscri\u00e7\u00e3o. Isso pode ajudar a melhorar sua convers\u00e3o na p\u00e1gina, pelo menos de forma incremental.<\/p>\n Aqui est\u00e1 uma p\u00e1gina de inscri\u00e7\u00e3o da Retool, com uma anima\u00e7\u00e3o e alguns logos na lateral:<\/p>\n Tamb\u00e9m fazemos isso na Kinsta para nossa p\u00e1gina de inscri\u00e7\u00e3o:<\/p>\n O conte\u00fado extra pode ajudar a lembrar o usu\u00e1rio do motivo pelo qual ele est\u00e1 assinando e por que ele precisa disso.<\/p>\n Sinto-me \u00e0 vontade para dizer que \u00e9 de conhecimento comum entre os desenvolvedores que as senhas s\u00e3o inerentemente inseguras, mas n\u00e3o<\/em> \u00e9 de conhecimento comum entre todas as pessoas que se inscrever\u00e3o no seu produto. Incentivar seus usu\u00e1rios a criar senhas seguras \u00e9 bom para voc\u00ea e bom para eles.<\/p>\n A Coinbase \u00e9 bastante rigorosa com a inscri\u00e7\u00e3o e exige que voc\u00ea use uma senha segura que seja mais complicada do que apenas seu primeiro nome:<\/p>\n Depois de gerar uma senha com meu gerenciador de senhas, eu estava pronto para come\u00e7ar:<\/p>\n A interface do usu\u00e1rio n\u00e3o me informou por que a senha n\u00e3o era segura o suficiente, nem quaisquer requisitos al\u00e9m de ter um n\u00famero. Incluir essas informa\u00e7\u00f5es no texto do seu produto tornar\u00e1 as coisas mais f\u00e1ceis para o usu\u00e1rio e ajudar\u00e1 a evitar a frustra\u00e7\u00e3o de ter que tentar outra senha.<\/p>\n Um em cada tr\u00eas americanos usa um gerenciador de senhas como o 1Password<\/a> e, mesmo assim, muitos formul\u00e1rios na web continuam a ignorar o `type=` nas entradas HTML. Fa\u00e7a com que seus formul\u00e1rios sejam compat\u00edveis com os gerenciadores de senhas<\/a>:<\/p>\n Isso pode fazer a diferen\u00e7a entre um login de 10 segundos incrivelmente f\u00e1cil e um login manual irritante, especialmente em dispositivos m\u00f3veis.<\/p>\n Depois que o usu\u00e1rio se autentica, voc\u00ea precisa escolher uma estrat\u00e9gia para manter esse estado nas solicita\u00e7\u00f5es subsequentes. O HTTP n\u00e3o tem estado e certamente n\u00e3o queremos pedir a senha do usu\u00e1rio em cada solicita\u00e7\u00e3o. H\u00e1 dois m\u00e9todos populares para lidar com isso<\/a> – sess\u00f5es<\/strong> (ou cookies) e JWTs<\/strong> (tokens da Web JSON) – e eles diferem em termos se o servidor ou o cliente faz o trabalho.<\/p>\n Na autentica\u00e7\u00e3o baseada em sess\u00e3o, a l\u00f3gica e o trabalho para manter a autentica\u00e7\u00e3o s\u00e3o tratados pelo servidor<\/strong>. Aqui est\u00e1 o fluxo b\u00e1sico:<\/p>\n \u00c9 bastante simples e pode ser ajustado em rela\u00e7\u00e3o ao tempo de dura\u00e7\u00e3o das sess\u00f5es, quando elas devem ser revogadas, etc. A desvantagem \u00e9 a lat\u00eancia em uma escala significativa, considerando todas as grava\u00e7\u00f5es e leituras no banco de dados, mas isso pode n\u00e3o ser uma considera\u00e7\u00e3o importante para a maioria dos leitores.<\/p>\n Em vez de lidar com a autentica\u00e7\u00e3o para solicita\u00e7\u00f5es subsequentes no servidor, os JWTs<\/a> permitem que voc\u00ea lide com elas (principalmente) no lado do cliente<\/strong>. Veja como funciona:<\/p>\n Com todo o trabalho de autentica\u00e7\u00e3o p\u00f3s-inicial transferido para o cliente, seu aplicativo pode ser carregado e funcionar muito mais r\u00e1pido. Mas h\u00e1 um problema principal: n\u00e3o h\u00e1 como invalidar um JWT do servidor. Se o usu\u00e1rio quiser fazer logout de um dispositivo ou se o escopo da autoriza\u00e7\u00e3o mudar, voc\u00ea precisar\u00e1 esperar at\u00e9 que o JWT expire.<\/p>\n Parte do que torna o Next.js excelente \u00e9 a renderiza\u00e7\u00e3o est\u00e1tica integrada – se a sua p\u00e1gina for est\u00e1tica, ou seja, n\u00e3o precisar fazer nenhuma chamada de API externa, o Next.js a armazenar\u00e1 automaticamente em cache e poder\u00e1 servi-la com extrema rapidez por meio de uma CDN. A vers\u00e3o anterior ao Next.js 13 sabe se uma p\u00e1gina \u00e9 est\u00e1tica se voc\u00ea n\u00e3o incluir nenhum `getServerSideProps` ou `getInitialProps` no arquivo, enquanto as vers\u00f5es posteriores ao Next.js 13 usam o React Server Components<\/a> para fazer isso.<\/p>\n Para autentica\u00e7\u00e3o, voc\u00ea tem uma op\u00e7\u00e3o<\/a>: renderizar uma p\u00e1gina est\u00e1tica de “carregamento” e fazer a busca no lado do cliente ou fazer tudo no lado do servidor. Para p\u00e1ginas que exigem autentica\u00e7\u00e3o [1]<\/a>, voc\u00ea pode renderizar um “skeleton<\/strong>” est\u00e1tico e, em seguida, fazer solicita\u00e7\u00f5es de autentica\u00e7\u00e3o no lado do cliente. Em teoria, isso significa que a p\u00e1gina \u00e9 carregada mais rapidamente, mesmo que o conte\u00fado inicial n\u00e3o esteja totalmente pronto para ser usado.<\/p>\n Aqui est\u00e1 um exemplo simplificado da documenta\u00e7\u00e3o que renderiza um estado de carregamento, desde que o objeto do usu\u00e1rio n\u00e3o esteja pronto:<\/p>\n Observe que voc\u00ea precisaria criar algum tipo de interface do usu\u00e1rio (UI) de carregamento aqui para manter o espa\u00e7o enquanto o cliente faz solicita\u00e7\u00f5es ap\u00f3s o carregamento.<\/p>\n Se quiser simplificar as coisas e executar a autentica\u00e7\u00e3o no lado do servidor, voc\u00ea poder\u00e1 adicionar sua solicita\u00e7\u00e3o de autentica\u00e7\u00e3o \u00e0 fun\u00e7\u00e3o `getServerSideProps`, e o Next aguardar\u00e1 para renderizar a p\u00e1gina at\u00e9 que a solicita\u00e7\u00e3o seja conclu\u00edda. Em vez da l\u00f3gica condicional no snippet acima, voc\u00ea executaria algo mais simples, como esta vers\u00e3o simplificada dos documentos do Next:<\/p>\n A l\u00f3gica presente ainda trata casos de falha na autentica\u00e7\u00e3o, mas redireciona para a tela de login ao inv\u00e9s de exibir um estado de carregamento.<\/p>\nBanco de dados tradicional<\/h3>\n
users<\/code> com as informa\u00e7\u00f5es fornecidas. Quando eles fazem login, voc\u00ea verifica as credenciais em compara\u00e7\u00e3o com o que est\u00e1 armazenado na tabela. Quando um usu\u00e1rio quer mudar sua senha, voc\u00ea atualiza o valor na tabela.<\/p>\nSolu\u00e7\u00f5es de autentica\u00e7\u00e3o do seu provedor de banco de dados<\/h3>\n
async function signInWithEmail() {\n const { data, error } = await supabase.auth.signInWithPassword({\n email: 'example@email.com',\n password: 'example-password',\n })\n}<\/code><\/pre>\nSolu\u00e7\u00f5es de autentica\u00e7\u00e3o que n\u00e3o s\u00e3o do seu provedor de banco de dados<\/h3>\n
![\"Auth0](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/Auth0-authentication.png\")
Single Sign-On (SSO)<\/h3>\n
Certo, ent\u00e3o qual deles \u00e9 para mim?<\/h3>\n
Criando rotas para inscri\u00e7\u00e3o e login, e dicas para voc\u00ea ir al\u00e9m da autentica\u00e7\u00e3o<\/h2>\n
\n
1. Atualize sua barra de navega\u00e7\u00e3o se houver uma sess\u00e3o ativa<\/h3>\n
![\"A](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage.png\")
![\"Mudan\u00e7as](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage-changes.png\")
2. Adicione algum conte\u00fado \u00fatil junto com o formul\u00e1rio de inscri\u00e7\u00e3o<\/h3>\n
![\"Se](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/retool-signup-page.png\")
![\"P\u00e1gina](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/mykinsta-sign-in.png\")
3. Se voc\u00ea estiver usando uma senha: sugira ou imponha uma senha forte<\/h3>\n
![\"Senha](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-create-account.png\")
![\"Senha](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-password-strength.png\")
4. Rotule suas entradas para que elas funcionem bem com um gerenciador de senhas<\/h3>\n
\n
Escolhendo entre sess\u00f5es e JWT<\/strong><\/h2>\n
Sess\u00f5es, tamb\u00e9m conhecidas como cookies<\/h3>\n
\n
Tokens da Web JSON (JWT)<\/h3>\n
\n
Escolhendo entre a autentica\u00e7\u00e3o do lado do servidor e do lado do cliente<\/h2>\n
import useUser from '..\/lib\/useUser'\n \nconst Profile = () => {\n \/\/ Fetch the user client-side\n const { user } = useUser({ redirectTo: '\/login' })\n \n \/\/ Server-render loading state\n if (!user || user.isLoggedIn === false) {\n \/\/ Build some sort of loading page here\n return <div>Loading...<\/div>\n }\n \n \/\/ Once the user request finishes, show the user\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nimport withSession from '..\/lib\/session'\n \nexport const getServerSideProps = withSession(async function ({ req, res }) {\n const { user } = req.session\n \n if (!user) {\n return {\n redirect: {\n destination: '\/login',\n permanent: false,\n },\n }\n }\n \n return {\n props: { user },\n }\n})\n \nconst Profile = ({ user }) => {\n \/\/ Show the user. No loading state is required\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nResumo<\/h2>\n