Implementar autenticación en una aplicación Next.js puede tomar apenas unos minutos cuando se utiliza AuthJS, la librería anteriormente conocida como Next Auth. Con un solo archivo y unas pocas líneas de código, es posible conectar proveedores de autenticación como GitHub aprovechando el protocolo OAuth (Open Authorization) y, más específicamente, OpenID Connect. A continuación se detalla el proceso paso a paso tal como se presenta en la práctica.
¿Cómo configurar una GitHub App para autenticación OAuth?
Antes de escribir código, es necesario registrar una aplicación en GitHub. El proceso comienza en el perfil de GitHub, dentro de Settings y luego en Developer settings [0:42].
- Se crea una nueva GitHub App con un nombre descriptivo, por ejemplo "AuthJS GitHub".
- Se indica una URL de página (puede ser temporal, como una página personal).
- Se define el callback URL siguiendo la convención de AuthJS:
http://localhost:3000/api/auth/callback/github [1:08].
- Se desactiva la opción de webhook, ya que no es necesaria para este caso.
- Se copia el client ID y se genera un client secret.
Estos dos valores deben almacenarse en las variables de entorno del proyecto para mantenerlos seguros y accesibles desde el código.
¿Qué estructura de archivos requiere AuthJS en Next.js?
Dentro de la carpeta api del proyecto, se crea una carpeta llamada auth. Dentro de ella se agrega un archivo con una convención especial: [...nextauth].js [1:50]. Este nombre representa una ruta dinámica (dynamic route) que Next.js interpreta para delegar todas las rutas de autenticación a la librería.
¿Cómo se configura el archivo principal de AuthJS?
El contenido del archivo es muy conciso [2:04]:
javascript
import NextAuth from "next-auth";
import GitHubProvider from "next-auth/providers/github";
export default NextAuth({
providers: [
GitHubProvider({
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET,
}),
],
});
El arreglo de providers acepta múltiples proveedores, lo que significa que una sola aplicación puede ofrecer varias estrategias de autenticación simultáneamente.
¿Cómo se envuelve la aplicación con el SessionProvider?
Para que la sesión esté disponible en toda la aplicación, se debe envolver el componente principal con el SessionProvider importado desde next-auth/react [2:42]:
javascript
import { SessionProvider } from "next-auth/react";
export default function App({ Component, pageProps: { session, ...pageProps } }) {
return (
<SessionProvider session={session}>
<Component {...pageProps} />
</SessionProvider>
);
}
Es fundamental extraer la prop session de pageProps y pasarla al SessionProvider. Olvidar este paso es un error común que impide que la sesión se inyecte correctamente.
¿Cómo se usa la sesión y el método signIn en los componentes?
Dentro de cualquier página o componente, se accede a la sesión mediante el hook useSession y se dispara el inicio de sesión con signIn, ambos importados desde next-auth/react [3:22]:
javascript
import { signIn, useSession } from "next-auth/react";
export default function Home() {
const { data, status } = useSession();
return (
<div>
{status === "authenticated" ? (
<p>Bienvenido, {data.user.name}</p>
) : (
<button onClick={() => signIn("github")}>Login with GitHub</button>
)}
</div>
);
}
- useSession retorna un objeto con
data (información del usuario) y status (que puede ser authenticated, unauthenticated o loading).
- Cuando solo se usa un proveedor, se puede pasar directamente el nombre
"github" al método signIn para evitar la pantalla de selección de proveedores [3:52].
Durante las pruebas en el navegador se encontraron dos errores frecuentes: el puerto mal escrito como 300 en lugar de 3000, y el protocolo configurado como https cuando en local debe ser http [4:18]. Tras corregirlos, la pantalla de request consent de GitHub apareció correctamente, y al autorizar la aplicación la autenticación funcionó sin problemas.
Agregar otro proveedor es tan simple como importar su módulo, configurar su client ID y client secret, y añadirlo al arreglo de providers. El reto propuesto es precisamente ese: implementar un proveedor diferente a GitHub y experimentar la flexibilidad de AuthJS. ¿Qué proveedor elegirías tú? Comparte tu experiencia en los comentarios.
