Buenos días Luigi, me gustaría agradecerte por este tutorial y todos los vídeos. He buscado contenido de este tipo en diversos lugares y tan completo como este no hay. Enhorabuena por tu trabajo! Pd: También estoy interesado en autenticación en dos pasos. :) Muchas gracias!
Te agradezco por tu apoyo, tu canal es el mejor y número 1 de UA-cam en este tema y tecnologías. Estaré esperando la implementación de autenticacion de dos pasos subela por favor 😢
Hola, para el tiempo de vida en la clase Client al RegisteredClient le añades otro campo: .tokenSettings(TokenSettings.builder().authorizationCodeTimeToLive(Duration.between(start, end).build()) Para el refresh token puedes crear la entidad Authorization y guardar los tokens en la base de datos tal como viene en el ejemplo de la documentación.
Ya vi tu curso y gracias por tu apoyo, es el mejor curso y canal de UA-cam qué he visto sobre la implementación de estas tecnologías todo un profesional, tengo una duda veo que en la clase AuthorizationSecurityConfig en el servidor de autenticacion dejaste el método OAuth2AuthorizationService con uso de la memoria localmente new InMemoryOAuth2AuthorizationService porque no lo hiciste persistente? Me podría apoyar en esa duda. Gracias de antemano. Además quedo a la espera del video de como implementar autenticacion de dos pasos por favor.
Hola, el autorizathionservice persistente lo utilizaríamos en el caso de querer persistir los tokens del usuario en cada sesión. Puedes ver el ejemplo en la documentación en el apartado how to guides -> implement core services with jpa
@@luigicode1480muchas gracias, para producción no hay inconveniente dejarlo en memoria o los debo de persistir?además quiero implementar el private_key_jwt en lugar del client_secret_basic, cuales son los cambios que haría o donde? Gracias por el apoyo de antemano Luigi.
Buenas noches, tenia una duda, entiendo que el servidor de autenticación se puede/debe usar con varios clientes , sirviendo de autenticación para infinidad de fronts, supongamos que tenemos un registro de usuario con algunos campos específicos de un proyecto como podrían ser , por ejemplo, tipo de juego favorito, si llevamos toda la parte de usuarios en el servidor de authentication, debemos almacenar estos campos en la base de datos del servidor de authentication? No me parece lógico ya que la tabla de usuario se llenaria con infinidad de campos que no les importan a otros proyectos... lo correcto seria programar un envío de los datos de usuario al servidor de recursos para que sea allí donde se almacenen los datos del usuario? Gracias de ante mano.
Hola. A ver, si tienes una cantidad de datos muy grandes asociados a un usuario, lo ideal es tener varias entidades con relaciones uno a muchos, muchos a uno etc, como por ejemplo, usuario y perfil. También es perfectamente posible tener datos de ese usuario en el resource server. Un ejemplo es Google, donde la cuenta de usuario sería el authorization server y los servidores de recursos Google Drive o Google fotos. Eso sí, ten en cuenta que al tener bases de datos independientes vas a tener una complejidad añadida a la hora de relacionar las entidades. Por último, sí esos datos son para un cliente en particular sería dicho cliente el encargado de almacenar y gestionar esos datos.
@@luigicode1480 hola , gracias por responder, la primera parte de tu respuesta no la he entendido del todo , quieres decir tener en la DB de autenticación relaciones entre usuario y perfiles y crear un perfil para cada front ? De la segunda parte entiendo que indicas que se puede tener, después del registro de usuario, un envío al backend (resource server) , con todos los datos del usuario para que se almacén allí. Es correcto? Gracias de antemano!!
Felicidades !!! soy tu fan :)
Buenos días Luigi, me gustaría agradecerte por este tutorial y todos los vídeos.
He buscado contenido de este tipo en diversos lugares y tan completo como este no hay.
Enhorabuena por tu trabajo!
Pd: También estoy interesado en autenticación en dos pasos. :)
Muchas gracias!
Te agradezco por tu apoyo, tu canal es el mejor y número 1 de UA-cam en este tema y tecnologías. Estaré esperando la implementación de autenticacion de dos pasos subela por favor 😢
Gracias , tenia un nudo en la cabeza jajaj, muy claro.
Muchas gracias por todos los videos del tutorial. Gran trabajo.
Muchas gracias por compartir el conocimiento he aprendido mucho gracias a usted
Excelente curso, muy bueno solo me quedo con la duda de como seria refrescar el token, y como establecer el tiempo de vida a este
Hola, para el tiempo de vida en la clase Client al RegisteredClient le añades otro campo:
.tokenSettings(TokenSettings.builder().authorizationCodeTimeToLive(Duration.between(start, end).build())
Para el refresh token puedes crear la entidad Authorization y guardar los tokens en la base de datos tal como viene en el ejemplo de la documentación.
@@luigicode1480 excelente! Muchas gracias por tu aporte
Ya vi tu curso y gracias por tu apoyo, es el mejor curso y canal de UA-cam qué he visto sobre la implementación de estas tecnologías todo un profesional, tengo una duda veo que en la clase AuthorizationSecurityConfig en el servidor de autenticacion dejaste el método OAuth2AuthorizationService con uso de la memoria localmente new InMemoryOAuth2AuthorizationService porque no lo hiciste persistente? Me podría apoyar en esa duda. Gracias de antemano. Además quedo a la espera del video de como implementar autenticacion de dos pasos por favor.
Hola, el autorizathionservice persistente lo utilizaríamos en el caso de querer persistir los tokens del usuario en cada sesión. Puedes ver el ejemplo en la documentación en el apartado how to guides -> implement core services with jpa
@@luigicode1480muchas gracias, para producción no hay inconveniente dejarlo en memoria o los debo de persistir?además quiero implementar el private_key_jwt en lugar del client_secret_basic, cuales son los cambios que haría o donde? Gracias por el apoyo de antemano Luigi.
Can U custom page login in angular, pls?? I try but not working 😢😢😢
Buenas noches, tenia una duda, entiendo que el servidor de autenticación se puede/debe usar con varios clientes , sirviendo de autenticación para infinidad de fronts, supongamos que tenemos un registro de usuario con algunos campos específicos de un proyecto como podrían ser , por ejemplo, tipo de juego favorito, si llevamos toda la parte de usuarios en el servidor de authentication, debemos almacenar estos campos en la base de datos del servidor de authentication? No me parece lógico ya que la tabla de usuario se llenaria con infinidad de campos que no les importan a otros proyectos... lo correcto seria programar un envío de los datos de usuario al servidor de recursos para que sea allí donde se almacenen los datos del usuario? Gracias de ante mano.
Hola. A ver, si tienes una cantidad de datos muy grandes asociados a un usuario, lo ideal es tener varias entidades con relaciones uno a muchos, muchos a uno etc, como por ejemplo, usuario y perfil.
También es perfectamente posible tener datos de ese usuario en el resource server. Un ejemplo es Google, donde la cuenta de usuario sería el authorization server y los servidores de recursos Google Drive o Google fotos. Eso sí, ten en cuenta que al tener bases de datos independientes vas a tener una complejidad añadida a la hora de relacionar las entidades.
Por último, sí esos datos son para un cliente en particular sería dicho cliente el encargado de almacenar y gestionar esos datos.
@@luigicode1480 hola , gracias por responder, la primera parte de tu respuesta no la he entendido del todo , quieres decir tener en la DB de autenticación relaciones entre usuario y perfiles y crear un perfil para cada front ? De la segunda parte entiendo que indicas que se puede tener, después del registro de usuario, un envío al backend (resource server) , con todos los datos del usuario para que se almacén allí. Es correcto? Gracias de antemano!!