Elegir un M\u00e9todo \/ Proveedor de Autenticaci\u00f3n<\/h2>\n
B\u00e1sicamente, hay 1.000 formas de incorporar la autenticaci\u00f3n a tu aplicaci\u00f3n. En lugar de centrarnos en proveedores concretos (tema para otra entrada del blog), veamos los tipos de soluciones de autenticaci\u00f3n<\/strong> y algunos ejemplos de cada una. En t\u00e9rminos de implementaci\u00f3n, next-auth<\/a> se est\u00e1 convirtiendo r\u00e1pidamente en una opci\u00f3n popular para integrar tu aplicaci\u00f3n Next.js con m\u00faltiples proveedores, a\u00f1adir SSO, etc.<\/p>\n Es de lo m\u00e1s sencillo: almacenas nombres de usuario y contrase\u00f1as en una base de datos relacional. Cuando un usuario se registra por primera vez, insertas una nueva fila en la tabla \u00abusuarios\u00bb con la informaci\u00f3n proporcionada. Cuando se conectan, compruebas las credenciales con lo que tienes almacenado en la tabla. Cuando un usuario quiere cambiar su contrase\u00f1a, actualizas el valor en la tabla.<\/p>\n La autenticaci\u00f3n tradicional de base de datos es, sin duda, el esquema de autenticaci\u00f3n m\u00e1s popular si observas la totalidad de las aplicaciones existentes, y ha existido b\u00e1sicamente desde siempre. Es muy flexible, barato y no te ata a ning\u00fan proveedor en particular. Pero tienes que construirlo t\u00fa mismo y, en particular, tienes que preocuparte de la encriptaci\u00f3n y de asegurarte de que esas valiosas contrase\u00f1as no caigan en manos equivocadas.<\/p>\n En los \u00faltimos a\u00f1os (y en honor a Firebase, desde hace ya bastantes a\u00f1os), se ha convertido en algo relativamente habitual que los proveedores de bases de datos administradas ofrezcan alg\u00fan tipo de soluci\u00f3n de autenticaci\u00f3n administrada. Firebase<\/a>, Supabase<\/a> y AWS<\/a> ofrecen tanto bases de datos administradas como autenticaci\u00f3n administrada como servicio a trav\u00e9s de un conjunto de API que abstrae f\u00e1cilmente la creaci\u00f3n de usuarios y la gesti\u00f3n de sesiones (m\u00e1s sobre esto m\u00e1s adelante).<\/p>\n Iniciar la sesi\u00f3n de un usuario con la autenticaci\u00f3n Supabase es tan sencillo como<\/a>:<\/p>\n Posiblemente a\u00fan m\u00e1s com\u00fan que la autenticaci\u00f3n como servicio de tu DBaaS sea la autenticaci\u00f3n como servicio de toda una empresa o producto. Auth0<\/a> existe desde 2013 (ahora es propiedad de Okta), y las \u00faltimas incorporaciones, como Stytch<\/a>, han dado prioridad a la experiencia del desarrollador y se han ganado cierto prestigio.<\/p>\n El SSO (siglas en ingl\u00e9s de Inicio de Sesi\u00f3n \u00danico, Single Sign On) te permite \u00abexternalizar\u00bb tu identidad a un proveedor externo, que puede ir desde un proveedor empresarial centrado en la seguridad, como Okta<\/a>, hasta algo m\u00e1s ampliamente adoptado, como Google<\/a> o GitHub. El SSO de Google es omnipresente en el mundo SaaS, y algunas herramientas centradas en el desarrollador s\u00f3lo<\/em> autentican a trav\u00e9s de GitHub.<\/p>\n Sea cual sea el proveedor que elijas, el SSO suele ser un add-on de los otros tipos de autenticaci\u00f3n anteriores y conlleva su propia idiosincrasia<\/a> en cuanto a la integraci\u00f3n con plataformas externas (atenci\u00f3n: SAML utiliza XML).<\/p>\n Aqu\u00ed no hay una elecci\u00f3n \u00abcorrecta\u00bb \u2014 lo adecuado para tu proyecto depende de tus prioridades. Si quieres poner las cosas en marcha r\u00e1pidamente sin una gran cantidad de configuraci\u00f3n inicial, subcontratar la autenticaci\u00f3n tiene sentido (incluso subcontratarla por completo, incluida la interfaz de usuario, a alguien como Auth0). Si prev\u00e9s una configuraci\u00f3n m\u00e1s compleja, construir tu propio backend de autenticaci\u00f3n tiene sentido. Y si prev\u00e9s dar soporte a clientes m\u00e1s grandes, necesitar\u00e1s a\u00f1adir SSO en alg\u00fan momento.<\/p>\n Next.js es tan popular en este momento que la mayor\u00eda de estos proveedores de autenticaci\u00f3n tienen documentaci\u00f3n y gu\u00edas de integraci\u00f3n espec\u00edficas para Next.js.<\/p>\n Algunos proveedores de autenticaci\u00f3n, como Auth0, proporcionan p\u00e1ginas web alojadas completas para el registro y el inicio de sesi\u00f3n. Pero si las creas desde cero, creo que es \u00fatil crearlas al principio del proceso, ya que las necesitar\u00e1s como redirecciones cuando implementes tu autenticaci\u00f3n.<\/p>\n As\u00ed que tiene sentido crear la estructura de estas p\u00e1ginas y luego a\u00f1adir las peticiones al backend. La forma m\u00e1s sencilla de implementar la autenticaci\u00f3n es tener estas dos rutas:<\/p>\n M\u00e1s all\u00e1 de lo b\u00e1sico, tendr\u00e1s que cubrir casos extremos, como cuando un usuario olvida su contrase\u00f1a. Algunos equipos prefieren tener el proceso de restablecimiento de contrase\u00f1a en una ruta separada, mientras que otros a\u00f1aden elementos din\u00e1micos de interfaz de usuario a la p\u00e1gina de inicio de sesi\u00f3n normal.<\/p>\n Puede que una p\u00e1gina de registro atractiva no suponga la diferencia entre el \u00e9xito y el fracaso, pero los peque\u00f1os detalles pueden dejar una buena impresi\u00f3n y, en general, proporcionar una mejor Experiencia de Usuario. Aqu\u00ed tienes una recopilaci\u00f3n de sitios web que han puesto un poco m\u00e1s de cari\u00f1o en sus procesos de autenticaci\u00f3n.<\/p>\n La llamada a la acci\u00f3n de Stripe en su barra de navegaci\u00f3n cambia en funci\u00f3n de si tienes una sesi\u00f3n autenticada o no. Este es el aspecto del sitio de marketing si no est\u00e1s autenticado. Observa la llamada a la acci\u00f3n para iniciar sesi\u00f3n:<\/p>\n Y este es el aspecto si est\u00e1s autenticado. Observa que la llamada a la acci\u00f3n cambia para llevar al usuario a su panel de control en lugar de iniciar sesi\u00f3n:<\/p>\n No cambia fundamentalmente mi experiencia con Stripe, pero es agradable.<\/p>\n Un apunte t\u00e9cnico interesante: hay una buena raz\u00f3n por la que la mayor\u00eda de las empresas no hacen que la barra de navegaci\u00f3n de su sitio de marketing \u00abdependa\u00bb de la autenticaci\u00f3n \u2014 supondr\u00eda una solicitud adicional a la API para comprobar el estado de autenticaci\u00f3n en cada carga de p\u00e1gina, que en la mayor\u00eda de los casos corresponde a visitantes que probablemente no lo est\u00e1n.<\/p>\n En los \u00faltimos a\u00f1os, especialmente en SaaS, las empresas han empezado a a\u00f1adir contenido a la p\u00e1gina de registro para \u00abanimar\u00bb al usuario a completar el registro. Esto puede ayudar a mejorar tu conversi\u00f3n en la p\u00e1gina, al menos incrementalmente.<\/p>\n Aqu\u00ed tienes una p\u00e1gina de registro de Retool, con una animaci\u00f3n y algunos logotipos en el lateral:<\/p>\n Tambi\u00e9n lo hacemos en Kinsta para nuestra p\u00e1gina de registro:<\/p>\n El peque\u00f1o contenido extra puede ayudar a recordar al usuario para qu\u00e9 se est\u00e1 registrando y por qu\u00e9 lo necesita.<\/p>\n Me siento c\u00f3modo diciendo que es de conocimiento com\u00fan entre los desarrolladores que las contrase\u00f1as son intr\u00ednsecamente inseguras, pero no<\/em> es de conocimiento com\u00fan entre todas las personas que se registrar\u00e1n en tu producto. Animar a tus usuarios a crear contrase\u00f1as seguras es bueno para ti y para ellos.<\/p>\n Coinbase es bastante estricta con el registro y exige que utilices una contrase\u00f1a segura que sea m\u00e1s complicada que tu nombre de pila:<\/p>\n Despu\u00e9s de generar una con mi gestor de contrase\u00f1as, pude empezar:<\/p>\n La Interfaz de Usuario no me dec\u00eda por qu\u00e9 la contrase\u00f1a no era lo suficientemente segura, ni ning\u00fan requisito m\u00e1s all\u00e1 de tener un n\u00famero. Si los incluyes en el texto del producto, facilitar\u00e1s las cosas al usuario y evitar\u00e1s la frustraci\u00f3n de tener que volver a intentar introducir la contrase\u00f1a.<\/p>\n Uno de cada tres estadounidenses utiliza un gestor de contrase\u00f1as como 1Password<\/a> y, sin embargo, muchos formularios web siguen ignorando el \u00abtype=\u00bb en las entradas HTML. Haz que tus formularios sean compatibles con los gestores de contrase\u00f1as<\/a>:<\/p>\n Puede marcar la diferencia entre un inicio de sesi\u00f3n de 10 segundos incre\u00edblemente fluido y uno manual molesto, especialmente en m\u00f3viles.<\/p>\n Una vez que tu usuario se autentique, tienes que elegir una estrategia para mantener ese estado a lo largo de las siguientes solicitudes. HTTP no tiene estado, y desde luego no queremos pedir a nuestro usuario su contrase\u00f1a en cada solicitud. Hay dos m\u00e9todos populares para manejar esto<\/a> \u2014 sesiones<\/strong> (o cookies) y JWTs<\/strong> (tokens web JSON) \u2014 y difieren en t\u00e9rminos de si el servidor o el cliente hace el trabajo.<\/p>\n En la autenticaci\u00f3n basada en sesiones, la l\u00f3gica y el trabajo para mantener la autenticaci\u00f3n son gestionados por el servidor<\/strong>. \u00c9ste es el flujo b\u00e1sico:<\/p>\n Es bastante sencillo y ajustable en cuanto a la duraci\u00f3n de las sesiones, cu\u00e1ndo deben revocarse, etc. La desventaja es la latencia a una escala significativa, dadas todas las escrituras y lecturas en la base de datos, pero eso puede no ser una consideraci\u00f3n importante para la mayor\u00eda de los lectores.<\/p>\n En lugar de gestionar la autenticaci\u00f3n de las solicitudes posteriores en el servidor, JWTs<\/a> te permiten gestionarlas (en su mayor parte) en el lado del cliente<\/strong>. Funciona as\u00ed<\/p>\n Con todo el trabajo posterior a la autenticaci\u00f3n inicial descargado en el cliente, tu aplicaci\u00f3n puede cargarse y funcionar mucho m\u00e1s r\u00e1pido. Pero hay un problema principal: no hay forma de invalidar un JWT desde el servidor. Si el usuario quiere desconectarse de un dispositivo o cambia el alcance de su autorizaci\u00f3n, tienes que esperar a que caduque el JWT.<\/p>\n Parte de lo que hace grande a Next.js es el renderizado est\u00e1tico incorporado \u2014 si tu p\u00e1gina es est\u00e1tica, es decir, no necesita hacer ninguna llamada a una API externa, Next.js la almacena autom\u00e1ticamente en cach\u00e9 y puede servirla extremadamente r\u00e1pido a trav\u00e9s de una CDN. La versi\u00f3n anterior a Next.js 13 sabe si una p\u00e1gina es est\u00e1tica si no incluye ning\u00fan `getServerSideProps` o `getInitialProps` en el archivo, mientras que las versiones posteriores a Next.js 13 utilizan Componentes de Servidor React<\/a> para hacerlo.<\/p>\n Para la autenticaci\u00f3n, puedes elegir entre<\/a>: renderizar una p\u00e1gina est\u00e1tica de \u00abcarga\u00bb y hacer la obtenci\u00f3n en el lado del cliente o hacerlo todo en el lado del servidor. Para las p\u00e1ginas que requieren autenticaci\u00f3n[1]<\/a>, puedes renderizar un \u00abesqueleto\u00bb est\u00e1tico y luego hacer las peticiones de autenticaci\u00f3n en el lado del cliente. En teor\u00eda, esto significa que la p\u00e1gina se carga m\u00e1s r\u00e1pido, aunque el contenido inicial no est\u00e9 totalmente listo.<\/p>\n Aqu\u00ed tienes un ejemplo simplificado de la documentaci\u00f3n que muestra un estado de carga mientras el objeto usuario no est\u00e9 listo:<\/p>\n Ten en cuenta que aqu\u00ed necesitar\u00edas construir alg\u00fan tipo de interfaz de usuario de carga para mantener el espacio mientras el cliente realiza peticiones tras la carga.<\/p>\n Si quieres simplificar las cosas y ejecutar la autenticaci\u00f3n en el lado del servidor, puedes a\u00f1adir tu solicitud de autenticaci\u00f3n en la funci\u00f3n `getServerSideProps`, y Next esperar\u00e1 a renderizar la p\u00e1gina hasta que se complete la solicitud. En lugar de la l\u00f3gica condicional del fragmento anterior, ejecutar\u00edas algo m\u00e1s sencillo como esta versi\u00f3n simplificada de los documentos de Next:<\/p>\n Aqu\u00ed sigue habiendo l\u00f3gica para gestionar cuando falla la autenticaci\u00f3n, pero redirige al inicio de sesi\u00f3n en lugar de mostrar un estado de carga.<\/p>\nBase de Datos Tradicional<\/h3>\n
Soluciones de Autenticaci\u00f3n de tu Proveedor de Bases de Datos<\/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>\nSoluciones de Autenticaci\u00f3n que No Provienen de tu Proveedor de Base de Datos<\/h3>\n
![\"La](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/Auth0-authentication.png\")
Inicio de Sesi\u00f3n \u00danico<\/h3>\n
Vale, \u00bfCu\u00e1l es Para M\u00ed?<\/h3>\n
Creaci\u00f3n de Rutas para el Registro y el Inicio de Sesi\u00f3n, y Consejos para Ir un Paso M\u00e1s All\u00e1 en la Autenticaci\u00f3n<\/strong><\/h2>\n
\n
1. Actualiza tu Barra de Navegaci\u00f3n Si Hay una Sesi\u00f3n Activa<\/h3>\n
![\"P\u00e1gina](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage.png\")
![\"Cambios](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage-changes.png\")
2. A\u00f1ade Contenido \u00datil Junto al Formulario de Registro<\/h3>\n
![\"P\u00e1gina](\"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. Si Utilizas una Contrase\u00f1a: Sugiere o Exige una Contrase\u00f1a Fuerte<\/h3>\n
![\"Crear](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-create-account.png\")
![\"Contrase\u00f1a](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-password-strength.png\")
4. Etiqueta Tus Entradas para que Funcionen Bien con un Gestor de Contrase\u00f1as<\/h3>\n
\n
Elegir Entre Sesiones y JWT<\/strong><\/h2>\n
Sesiones, Tambi\u00e9n Conocidas como Cookies<\/h3>\n
\n
Tokens Web JSON (JWT)<\/h3>\n
\n
Elegir entre la Autenticaci\u00f3n en el Lado del Servidor y en el Lado del Cliente<\/strong><\/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>\nResumen<\/h2>\n