Think twice. Code once.

Saltar al contenido
  • Home
  • Website
  • Contact

Como crear un acceso único para varias aplicaciones – Introducción

2 respuestas

Cuando se gestionan varias aplicaciones para un mismo grupo de usuarios (como suele pasar en la mayoría de las empresas), es un verdadero fastidio tener que identificarse en cada una de las distintas aplicaciones, más aún cuando en cada una los criterios de acceso son completamente distintos: en uno se identifica con email, en otro con un nombre de usuario, diferentes contraseñas, etcétera.

Para solventar este problema, la mejor opción es crear un único acceso y una vez el usuario se haya identificado, podrá acceder a todas las aplicaciones a las que tenga acceso.

Para quien todavía no entiende de lo que estamos hablando, el ejemplo más conocido es Google. Una vez que te identificas con tu cuenta de Google, tienes acceso a todos sus sitios y aplicaciones: Gmail, Youtube, Maps, Analytics, etcétera.

Además, lo mejor de todo esto, es que al tener nuestros usuarios centralizados en una sóla base de datos, tendremos una mejor gestión y monitorización sobre todos los usuarios del sistema, evitando también los fallos de seguridad que puedan existir en los procesos de autentificación en alguna de nuestras aplicaciones.

En esta serie de artículos os vamos a mostrar como crear este sistema de acceso único desde cero. Pero en el artículo actual, sólo vamos a hacer una introducción sobre qué tecnologías y metodologías vamos a utilizar para crear este sistema.

Como nuestro sistema será una API REST, podremos integrarlo con cualquier tipo de aplicación: web, móvil, escritorio, etcétera.

¿Qué podrá hacer nuestro sistema?

Nuestro sistema gestionará lo siguiente:

  • Usuarios
    • Crear / Editar / Eliminar
    • Habilitar y deshabilitar cuentas de usuario.
    • Búsqueda de usuarios
    • Recuperar contraseñas
    • Validación contra servidor LDAP (Active Directory)
  • Roles de usuarios (API)
    • Administrador
    • Usuario genérico
  • Aplicaciones
  • Roles de los usuarios en las aplicaciones
  • Datos adicionales de los usuarios necesarios para las aplicaciones
    • Si por ejemplo en una de nuestras aplicaciones necesitamos guardar y conocer el «Centro de trabajo» del usuario actual, este dato lo podemos guardar en la base de datos de nuestra aplicación y sincronizarlo con nuestra API. Así, si modificamos este dato en cualquier usuario desde el sistema, la API sincronizará los cambios en la base de datos de la aplicación y viceversa.

¿Y cómo va a funcionar todo esto?

La forma rápida de explicarlo sería así:

Todas nuestras aplicaciones preguntarán en cada petición a nuestro sistema de acceso único si el usuario es válido (está autentificado) y tiene permisos de acceso a dicha aplicación.

login-unico-esquema

Representación gráfica (click para ampliar)

Y ahora vamos a entrar un poco más en detalle:

Para poder crear un login único en todas las aplicaciones se utiliza un proceso de autentificación llamado JWT (Javascript web tokens).

¿Cómo funciona el proceso de autentificación?

Los usuarios se identifican a través de un Front-End en el que aparece un formulario de login.

Cuando se envía el formulario, el Front-End hace una petición a la API para comprobar si las credenciales proporcionadas por el usuario son correctas.

En el caso de que las credenciales sean correctas, se crea una cookie en el navegador que contiene el JWT (en el caso de las aplicaciones web), la cual es válida para todos los subdominios de nuestro dominio *.albertolabs.com.

¿Cómo saben las aplicaciones si mi cookie es válida?

Las aplicaciones que están integradas, comprueban en cada petición si el JWT que contiene la cookie es válido preguntando a la API.

Para que el JWT sea válido, se deben cumplir ciertas condiciones previamente definidas:

  • Que el JWT se haya generado desde el servidor / RSA Public / Private keys.
  • El usuario tiene que estar habilitado (tanto en la bbdd de la API).
  • El usuario debe tener acceso (un rol asignado) a la aplicación a la que se accede.

Si el JWT es válido y se cumple lo mencionado anteriormente, podemos acceder a la aplicación, de no ser válido, nos enviará al Front-End para que nos identifiquemos.

¿Qué información contiene el JWT?

El JWT contiene la información básica del usuario que proporciona desde la tabla Users en la base de datos de la API.
También incluye el listado de aplicaciones a las que el usuario tiene acceso junto con su rol correspondiente.

Ejemplo del contenido de un JWT:

{
  "id": 13,
  "type": "api",
  "username": "albertolabs",
  "email": "info[at]albertolabs[dot]com",
  "role": [
    "ROLE_SUPERADMIN"
  ],
  "name": "Alberto",
  "surnames": "~",
  "avatar": null,
  "apps": {
    "intranet": {
      "role": "ROLE_SUPERADMIN"
    },
    "issues_portal": {
      "role": "ROLE_SUPERADMIN"
    }
  },
  "exp": 1495034731,
  "iat": 1495002331
}

En el próximo artículo comenzaremos con la parte técnica y con el desarrollo de nuestra API.

Share this:

  • Facebook
  • X

Relacionado

Alberto
Alberto

A young developer from Madrid who loves programming and computing. Constantly testing with new technologies and thinking in new projects and challenges.

Esta entrada se publicó en JWT, MySQL, Otros, PHP, Symfony y está etiquetada con acceso, api, autentificación, auth, authentication, cookie, cookies, gestión usuarios, jwt, login, sistema, único, usuarios en 18 agosto, 2017 por Alberto.

Navegación de entradas

← Cómo crear un contenedor Docker con PHP y Nginx Creating alias for Linux command line →


Categorías

  • Docker
  • GIT
  • Javascript
  • JWT
  • Linux
  • MySQL
  • Nginx
  • Otros
  • PHP
  • Sin categoría
  • Symfony
  • Windows
  • Wordpress

Etiquetas

acceso adress alias api autentificación auth authentication backup bin branch can't connect composer contenedor cookie cookies cvs database disable docker docker-compose fecha formatear gestión usuarios git hora jwt linux login mysql mysql-server nginx php phpdocker plugin project promt remote connection sistema symfony update updates usuarios website wordpress único

©  Albertolabs - 2025