ASP.

NET Core Web API

Desarrollo Web en Entorno
Servidor
Contenidos
● Introducción
● Nuevo proyecto [Link] Core Web API
● Persistencia de datos
● Autenticación y Autorización
Introducción
Una API (Application programming Interface) es un software del lado servidor
que ofrece un conjunto de servicios o funciones que pueden ser usados por
un cliente.
Introducción BD

GET / POST / PUT / DELETE

P I
INTERNET

A
Request

Response
Introducción
[Link] Core permite la creación de web APIs de dos tipos:

● APIs que usan Controladores

● APIs mínimas

En este curso usaremos las primeras, ya que son las que mejor se adaptan al
crecimiento y expansión de un proyecto de este tipo.

A diferencia de MVC, la respuesta del servidor al cliente siempre será un JSON

y no una vista, por lo que en el caso del desarrollo de APIs solo tendremos
Modelos y Controladores.

Muchos de los conceptos de la unidad anterior se utilizarán aquí.

AUT03_01 Qué es un Servicio
[Link]

[Link]

……

1. Qué es un servicio web?

2. API Web vs. Rest API
[Link] Core Web API: Estructura
Para crear un proyecto de este tipo, seleccionaremos la siguiente plantilla:

Y dejaremos las opciones que vienen por defecto:

[Link] Core Web API: Estructura
Se genera un nuevo proyecto, con un pequeño ejemplo de funcionamiento,
que tiene la siguiente estructura:

Controlador del Modelo

Configuración del proyecto

Inicializador del proyecto

Clase del Modelo

Casi todos los elementos nos resultan familiares, pero veamos las
particularidades de este tipo de proyectos…
[Link] Core Web API: Estructura
[Link]

Se incluyen los controladores sin vistas

Permite indicar los puntos de conexión (end

points) en los controladores

Se incluyen la herramienta Swagger a

nuestra aplicación

Permite mapear las rutas a los controladores

en este punto (de momento no lo usaremos)
[Link] Core Web API: Estructura
Controladores

En una API los Controllers no devuelven vistas como en MVC, sino JSON, por lo
que el retorno de sus métodos serán distintos.

La cabecera del controlador tiene las siguientes particularidades

● [ApiController] → Indica que es un controlador para una API

● [Route(“[controller]”] → Indica si la ruta de acceso tuviera algún prefijo
● ControllerBase → Todos los controladores de una API implementan esta
interfaz, que determina que es un controlador pero no utiliza vistas.
[Link] Core Web API: Estructura
Controladores → Acciones

Si existiera ambigüedad a la hora de determinar qué acción del controlador es

la que se ha de ejecutar para un endpoint determinado, se puede establecer
un nombre concreto para una acción, el cual pasará a formar parte del
endpoint de esa acción.

Esta ambigüedad se produce cuando existen al menos dos acciones del

mismo método HTTP que acepten los mismos parámetros.

Para romper esta ambigüedad usamos estos atributos en la acción:

[Link] Core Web API: Ejecución del proyecto
Al ejecutar el proyecto se abre el una
página de Swagger, que es un
framework de código abierto que
ofrece herramientas para diseñar,
construir, documentar y utilizar
servicios web RESTful.

Nombre del controlador

Conjunto de servicios que ofrece el

controlador WeatherForecast (En este
caso el controlador solo tiene 1
servicio de tipo GET)

Esquemas de los modelos que utilizan

los servicios de la aplicación
[Link] Core Web API: Ejecución del Proyecto
Si observamos los servicios que muestra Swagger en su página, vemos que
nos indica el endpoint de acceso a cada servicio.
Para este ejemplo solo está el endpoint → /WeatherForecast

Teniendo el proyecto en ejecución, podemos acceder a los recursos por otras

vías distintas a las de Swagger:
● Mediante el navegador web:
○ Indicaremos el host y el endpoint del servicio en el navegador.
○ Esta forma tiene la limitación de que solo podemos consultar los servicios de tipo GET
● Mediante Postman (o herramientas similares)
○ Permite todo tipo de peticiones, mediante métodos HTTP, a la API (GET, POST, PUT y
DELETE serán las que usaremos)
[Link] Core Web API: Consumir los Servicios API
Consulta Mediante Página Swagger

Sobre el servicio en concreto, lo desplegamos y pulsamos “Try it out”.

Tras esto pulsamos “Execute”. Si el servicio requiere datos para enviar al

backend, se tendrá que introducir la información necesaria antes de pulsar
“Execute”.

Se tendrá que introducir datos en caso de querer ver detalles de un item, para
crearlo, modificarlo o eliminarlo.

Tras ejecutar nos ofrece el comando Curl que realiza la acción, así como la
URL para realizar la petición, además del resultado de la consulta.
[Link] Core Web API: Consumir los Servicios API
Consulta Mediante Página Swagger
[Link] Core Web API: Consumir los Servicios API
Consulta Mediante Navegador Web

Host y Puerto Punto de acceso

[Link] Core Web API: Consumir los Servicios API
Consulta Mediante Postman
[Link] Core Web API: Modelos
Los modelos en este tipo de aplicaciones no difieren de los modelos utilizados
en los proyectos de MVC.

Estos podrán ser generados mediante ingeniería inversa (Database First) o

manualmente en el código para generar su correspondencia en la BD (Code
First) como ya vimos en la parte de persistencia de datos en MVC.

Al igual que en MVC, podremos hacer scaffold de un modelo para generar su

controlador (en este caso no se generan vistas) seleccionando el tipo de
controlador adecuado.

Este controlador generado contendrá los métodos necesarios para realizar las
operaciones CRUD del modelo, como veremos más adelante.
[Link] Core Web API: Modelos
Validación del Modelo

Al igual que ya vimos, en la definición del modelo se deberán incluir los

atributos de validación que sean necesarios para que este se adapte a las
necesidades de la aplicación y definición de los campos de la base de datos.

Estos atributos nos servirán para validar los datos de los modelos que se
quieran crear o editar en las peticiones correspondientes.

Para verificar que el modelo recibido en la acción cumple con las restricciones,
usaremos la misma estrategia que en MVC:
[Link] Core Web API: Controladores
Como ya hemos comentado, los controladores de una API tiene ciertos
aspectos particulares.

A nivel general de controlador, estos controladores tienen una apariencia

similar a la siguiente en su declaración:

Estos atributos e interfaces ya han sido explicadas con anterioridad.

En cuanto a las acciones de los controladores, también tienen

particularidades que vamos a enumerar.
[Link] Core Web API: Controladores
Los servicios que ofrece una API, implementados en nuestros proyectos por
acciones de controladores, no retornan vistas como en MVC, sino que
retornan una respuesta más compleja compuesta de:

● Status Code:
○ Indica los posibles distintos estados de la petición devuelta por el servidor.
○ Este dato lo puede retornar automáticamente nuestra API o podemos definir
exactamente el código que queremos devolver.
● Headers
○ Se compone de distintos campos posibles.
○ El framework construye esta parte automáticamente, aunque se puede personalizar.
● Body
○ Esta es la parte en la que retornaremos el JSON con datos cuando sea necesario.
○ No siempre es necesario retornar datos (Ejemplo: en un DELETE)
○ Esta parte la tendremos que especificar.
[Link] Core Web API: Controladores
En cuanto a los tipos de datos que retornan las acciones de los controladores,
tenemos varios tipos:

● Tipos de datos específicos:

○ Se pueden retornar “void”, “string”, “List<T>”, etc.
○ Estos datos serán convertidos a JSON automáticamente.
○ Con este tipo de retorno no podemos especificar un Status Code
● IActionResult:
○ Este tipo nos permite especificar el Status Code de la respuesta y datos de retorno.
○ Existe una larga lista de respuestas de este tipo de la interfaz ControllerBase que
implementan nuestros controladores de API.
○ Esta respuesta puede ser síncrona o asíncrona, de igual forma que en MVC.
● ActionResult<T>:
○ Es muy similar al anterior.
○ Permite especificar el tipo de dato que se retorna.
[Link] Core Web API: Controladores
Las respuestas, en forma de métodos, que usaremos más comunmente en las
acciones que retornen IActionResult o ActionResult serán las siguientes
(algunos pueden tener parámetros que se pueden consultar aquí):
● Ok()
○ Devuelve Status 200 y los datos que pasemos por parámetro.
○ Se usa para una consulta exitosa de lectura de datos.
● CreatedAtAction()
○ Devuelve Status 201, la ruta al recurso creado en el header de la respuesta y el elemento
creado (en formato json) en el body de la respuesta.
○ Se utiliza cuando se crea un elemento de un modelo con éxito.
● NotFound()
○ Devuelve Status 404
○ Se utiliza cuando no se encuentra un recurso
● BadRequest()
○ Devuelve Status 400
○ Se utiliza cuando algo en la petición no es correcto
[Link] Core Web API: Controladores
Atributo ProducesResponseType

Este atributo de las acciones de nuestra Web API nos permite especificar los
tipos de retorno que tienen estas acciones. Se corresponden con los métodos
retornados en las acciones que devuelven IActionResult y ActionResult<T>

Especificar esto es una buena práctica que ayuda a la mejor documentación

de la API desarrollada.

Definen el Status Code de la respuesta, y un ejemplo sería el siguiente:

[Link] Core Web API: Crear Controladores
A la hora de incluir un nuevo controlador a la aplicación, veremos que hay
varios tipos de los que pertenecen a la categoría API

Generamos un nuevo
controlador de este tipo, que
no está ligado a un modelo
en concreto.
De momento no utilizamos
persistencia de datos.
[Link] Core Web API: Crear Controladores
Controlador de API con acciones de lectura y escritura
[Link] Core Web API: Controladores
Resultado en la página de Swagger

Se mostrarán todos los servicios, y el tipo de cada uno, que tiene el

controlador generado (de nombre Values).

Podremos testear cada servicio en esta herramienta.

Ejercicio 1
Realizar las siguientes acciones:

● Generar un nuevo proyecto [Link] Core Web API

● Quitar del proyecto los modelos o controladores incluidos por defecto.
● Generar un nuevo controlador de acciones de lectura y escritura que no esté ligado a un
modelo en concreto.
● Crear un modelo para Juegos que tenga los siguientes campos:
○ Id
○ Título -> obligatorio y longitud entre 5 y 15 caracteres
○ Género -> obligatorio y longitud entre 2 y 12 caracteres
● Modificar el controlador generado para que contenga un listado de juegos (con 3 juegos
iniciales) y que permita realizar las acciones CRUD sobre los elementos de esta lista.
● Las acciones han de retornar el tipo IActionResult o ActionResult<T>
● Incluir validación del modelo recibido al crear y actualizar modelos, en base a los atributos de
validación que hay que incluir en el modelo.
● Incluir atributos ProducesResponseTypes
● Se ha de poder consumir todos estos servicios desde postman o swagger
○ Crear una colección en postman que contenga todas las peticiones de estos servicios creados
○ Crear variables a nivel de colección para el puerto y el host
○ Exportar el conjunto de peticiones de la colección creada
Persistencia de Modelos
La persistencia de los Modelos en una Web API se realiza de la misma forma
que en una aplicación MVC.

Tanto si se han usado técnicas de Code First o de Database First, los elementos
que entran en juego en el proceso de persistencia de los datos de los modelos
son las mismas.

Si existieran relaciones entre los modelos en cualquiera de sus formas

(one-to-one, one-to-many o many-to-many) la forma de proceder no difiere a
como se ha realizado anteriormente en MVC.

De igual forma, se podrán usar técnicas de scaffold sobre estos modelos para
generar los controladores correspondientes.
Persistencia de Modelos
Referencias Circulares:
Cuando se trata de serializar modelos que están involucrados en relaciones
one-to-many o many-to-many se corre el riesgo de generar referencias
circulares.
Esto sucede por que el Modelo A referencia al Modelo B, que puede tener una
lista de los Modelos A que tiene, que a su vez tienen referencias a un Modelo
B, y así cíclicamente hasta el infinito.
Estas referencias circulares hay que cortarlas por que si no se generaría un
JSON de tamaño infinito como respuesta, aunque se llenaría la memoria
principal de la máquina antes de llegar a eso.
Persistencia de Modelos
Referencias Circulares:
Persistencia de Modelos
Referencias Circulares: Soluciones

Existen varias maneras de resolver la generación de referencias circulares o

cíclicas cuando serializamos un objeto para convertirlo en JSON.

Las principales técnicas son las siguientes:

● Ignorar Ciclos, cuando se serializa el objeto en JSON

● Seleccionar los campos que contendrá el JSON final
Persistencia de Modelos
Referencias Circulares: Soluciones

● Ignorar Ciclos

Se añade una opción al servicio de controladores, en [Link], para que se

ignoren los ciclos redundantes.
Persistencia de Modelos
Referencias Circulares: Soluciones

● Seleccionar los campos que contendrá el JSON final

[Link] Core Web API: Crear Controladores
En base a un modelo se puede generar mediante scaffold un controlador de
este modelo.

Generamos un nuevo
controlador de este tipo que
esté ligado a un modelo
existente.
Esto genera el controlador
del modelo y la clase de
contexto para acceso a la BD
en caso de que no existiera
uno aún.
Ejercicio 2
Realizar las siguientes acciones:
● Generar un nuevo proyecto [Link] Core Web API
● Quitar del proyecto los modelos o controladores incluidos por defecto.
● Crear dos modelos, Game y Genre, que tengan entre ellos una relación one-to-many.
● Utilizar técnicas de Code First para generar la base de datos y tablas correspondientes a
los modelos creados.
● Crear, mediante scaffold, los controladores con acciones de lectura y escritura de estos
modelos.
● Revisar los controladores para asegurar que realizan todas las operaciones CRUD
correctamente. Al listar y ver detalles de Juegos o Géneros, estos han de mostrar los
campos del modelo género al que pertenecen, en el primer caso, y el listado de juegos
del género, en el segundo.
● Añadir los atributos necesarios a cada acción para que en Swagger se pueda ver los
códigos de estado que devuelven.
● Se ha de poder consumir todos estos servicios desde postman o swagger
○ Crear una colección en postman que contenga todas las peticiones de estos servicios creados
○ Crear variables a nivel de colección para el puerto y el host
○ Exportar el conjunto de peticiones de la colección creada
Autenticación y Autorización
Una API, al igual que una aplicación MVC como las de la unidad anterior,
pueden tener recursos que no deberían ser accesibles para todo cliente que
lo solicite.

Para proteger los accesos a los recursos existen varias opciones:

● Compartir usuario y contraseña

○ Esta opción está en desuso, ya que compartir usuario y contraseña en cada petición
aumenta las posibilidades de que estas credenciales sean tomadas por alguien.
● Uso de cookies
○ Si se produce una autenticación satisfactoria, el sistema ofrece una cookie, como en MVC.
Esto permitiría el acceso a la API. El problema de esta opción es el Cross-Site Request
Forgery (CSRF), ya que la cookie está disponible en todas las tabs del navegador.
● Uso de tokens
○ Esta será la opción que veremos. Existen distintos tipos de tokens.
Autenticación y Autorización
El proceso de autenticación, por el que se obtiene el token para realizar
sucesivas peticiones, es el siguiente:
● El usuario hace una petición al servidor API con sus credenciales (usuario
y contraseña) para identificarse.
○ Este servidor que identifica al usuario y genera el token puede ser el mismo que ofrece
los recursos API o un servidor de un tercero que ofrezca este servicio.
● El servidor retorna el token al usuario
● El usuario utiliza ese token como medio de identificación en sucesivas
peticiones a los recursos de la API.
Veamos los diagramas que representan los dos posibles escenarios
planteados:
Autenticación y Autorización
SERVIDOR DE AUTORIZACIÓN DE TERCEROS
Autenticación y Autorización
SERVIDOR DE AUTORIZACIÓN DE TERCEROS
Para implementar este tipo de autenticación, [Link] Core ofrece las
siguientes opciones:
● IdentityServer4: Este servicio de autenticación para APIs se utilizó
ampliamente años atrás, pero dejó de estar mantenido desde 2020.
● Duende IdentityServer: Es la sucesión del anterior. Tiene versión
gratuita para ámbito académico, desarrollo local e incluso para pequeñas
empresas que facturen menos de una cantidad dada.
● Azure App Service Authentication: es una buena opción si todo el
ecosistema de la aplicación está integrado en Azure.
De forma similar, se puede utilizar proveedores de autenticación, para
identificar al usuario y generar el token, como pueden ser Facebook, Google o
Twitter.
Autenticación y Autorización
SERVIDOR DE AUTORIZACIÓN PROPIO
Autenticación y Autorización
SERVIDOR DE AUTORIZACIÓN PROPIO
Como ya se ha comentado, este será el esquema de autenticación que
utilizaremos en esta unidad, con el fin de entender el proceso de
autenticación y autorización en una API mediante Token.
El tipo de token que utilizaremos será el JSON Web Token (JWT).
JWT es un estándar que define una forma segura y compacta de transmitir
información entre dos entidades en forma de un objeto JSON.
Esta información puede ser verificada y es confiable, ya que está firmada
digitalmente.
Los JWTs pueden ser firmados utilizando una llave privada, mediante un
algoritmo HMAC en el ejemplo que veremos.
Autenticación y Autorización
SERVIDOR DE AUTORIZACIÓN PROPIO

El uso de JWTs es de especial utilidad cuando existen necesidades de

autenticación (para conocer quién es el usuario que hace la petición) y de
autorización (para saber a qué recursos puede acceder el usuario que realiza
la petición).

Como veremos a continuación, un token JWT contiene información acerca del

usuario, como puede ser los roles que posee, y gracias a ello determinar si
está autorizado a acceder a cada uno de los recursos de nuestra API.
Autenticación y Autorización
ESTRUCTURA DE UN JWT

Un token de este tipo es un JSON codificado en Base64 que presenta forma de

cadena de caracteres alfanuméricos.

Esta cadena está dividida en tres partes separadas por puntos, como ejemplo:

[Link]

Cada una de estas partes representa lo siguiente:

● Encabezado (header)
● Contenido (payload)
● Firma (signature)
Autenticación y Autorización
ESTRUCTURA DE UN JWT → Encabezado (Header)

El encabezado consiste en dos partes:

● El tipo de token, que será JWT

● El algoritmo utilizado para ser firmado. Puede ser HMAC, SHA256 o RSA

Por ejemplo:

Este JSON será codificado en Base64 para formar parte del primer segmento
del JWT.
Autenticación y Autorización
ESTRUCTURA DE UN JWT → Contenido (Payload)
Es la parte que contiene los claims, que podríamos definirlo como los derechos que
tiene un usuario.

Hay tres tipos de claims:

● Claims estándares: No son obligatorios, pero sí recomendados.

Autenticación y Autorización
ESTRUCTURA DE UN JWT → Contenido (Payload)

● Claims particulares:
○ Estos son definidos por quien define el JWT.
○ Pueden contener información sobre el usuario, sus roles, etc.
○ Para evitar colisiones de nombres, es recomendable usar los identificadores
definidos por la IANA JSON Web Token Registry
○ Dado que la información de este segmento es visible, es importante NO
INCLUIR información sensible en el payload.
○ Un ejemplo de este payload, antes de convertirlo a Base64, sería el siguiente:
Autenticación y Autorización
ESTRUCTURA DE UN JWT → Firma (Signature)
Para crear la firma debemos tomar el header codificado, el payload codificado, una llave
secreta (definida en nuestro archivo de configuración), el algoritmo especificado en el
header y firmar todo eso.

Dado que el token JWT puede ser visualizado por el usuario, decodificado y modificado,
la firma se usará para verificar que el contenido del JWT no ha cambiado por parte del
usuario o mientras viaja por la red.

Esta firma garantiza que el contenido (payload) del JWT es el mismo que el que se emitió
en primer lugar.

Algunos ejemplos visuales de este formato de los JWTs podrían ser los siguientes:
Autenticación y Autorización
ESTRUCTURA DE UN JWT
Autenticación y Autorización
ESTRUCTURA DE UN JWT
Autenticación y Autorización
ESTRUCTURA DE UN JWT
Autenticación y Autorización
FORMA DE USO DE LOS JWTs

Tras la autenticación del usuario en un servidor de autenticación (propio o

ajeno) este recibe el token.

Este token se incluirá en la cabecera de la petición del método HTTP

correspondiente, en el campo “Autorization”, que usa la sintaxis:

● Tipo será “Bearer” en nuestro caso.

● Credenciales será el token recibido tras la autenticación.
Autenticación y Autorización
FORMA DE USO DE LOS JWTs
Dado que una Web API (al igual que las MVC) son stateless, siempre será
necesario que el token vaya incluido en el encabezado de la petición.
De esta forma se podrá verificar para determinar si el token es válido o no, y si
lo es, leer la información que incluye para ser usada en la solicitud si fuera
necesario.
Esto reduce las consultas a BD para leer la información del usuario en cada
petición, ya que el token contiene información como username, email, roles,
etc.
Dado que el token va incluido en el header, no habrá problemas con el
Cross-Origin Resource Sharing (CORS) ya que no se utilizan cookies, que sí
funcionan por dominio.
Autenticación y Autorización → Implementación
Para poder definir las distintas acciones que hay que realizar para poder utilizar técnicas de
autenticación y autorización en nuestra API, mediante Tokens JWT emitidos por nuestro
propio servidor (que hará las funciones de servidor de autorización), será necesario partir
de un proyecto que cumpla las siguientes condiciones:

● Proyecto [Link] Core Web Api con controladores

● Al menos un modelo emparejado con una tabla en una base de datos (ya sea mediante
Code First o mediante Database First) utilizando EF Core.
● Inclusión de los siguientes paquetes NuGet de Identity:
○ [Link]
○ [Link]
● Incluir servicio Identity en el constructor de la aplicación ([Link]). En esta ocasión
se usará la llamada “AddIdentityCore”.
● Haber generado en la BD las tablas que utiliza Identity mediante Migraciones y
actualizaciones de la BD.
● Haber sembrado las tablas con usuarios, roles y sus relaciones, como vimos en MVC.
Autenticación y Autorización → Implementación
Partiendo del escenario descrito, se tendrán que realizar las siguientes
acciones para poder incluir autenticación y autorización mediante tokens JWT:

● Instalar paquetes NuGet necesarios

● Modificar archivo de configuración
● Modificar [Link]
● Crear AuthController para realizar las acciones de Login y Register
Autenticación y Autorización → Implementación
INSTALAR PAQUETES NUGET NECESARIOS

El único paquete necesario, para utilizar tokens JWT en nuestro proyecto, es el

siguiente:
Autenticación y Autorización → Implementación
MODIFICAR ARCHIVO DE CONFIGURACIÓN

En nuestro archivo de configuración ([Link]) se tendrán que añadir

lo siguiente:

El campo Issuer identifica el proveedor de

identidad que emitió el Token

Identifica la audiencia o receptores para lo

que el JWT fue emitido, normalmente
el/los servidor/es de recursos (e.g. la API
protegida)

Clave privada que se usará para firmar el

token generado o recibido
Autenticación y Autorización → Implementación
MODIFICAR [Link]

Incluir Servicio Identity

Ya se ha indicado que se ha de partir de un proyecto que use el servicio

Identity, pero hay que aclarar que:

● En MVC se usaba AddDefaultIdentity<TUser>() como servicio de Identity,

que incluye interfaz de usuarios predeterminada.
● En API, podremos invocar el uso de Identity como servicio de dos formas:
○ AddIdentityCore<TUser>() → proporciona servicios de identity a la aplicación, con soporte
a usuarios. Si se quieren usar roles se tendrá que usar AddRoles como vimos.
○ AddIdentity<TUser, Trole>() → proporciona servicios de Identity con soporte a usuarios y
roles.
Autenticación y Autorización → Implementación
MODIFICAR [Link] → Añadir Servicio de Autenticación

Dado que usaremos un token JWT de tipo Bearer como esquema de

autenticación, tendremos que incluir este servicio al constructor de la
siguiente forma:

Vemos que se ha especificado un esquema “JWT Bearer” para la autenticación,

y se invocado al método “AddJwtBearer” al que se le pasan una serie de
opciones de configuración del funcionamiento de este esquema de
autenticación.

Las opciones utilizadas podrían ser como las siguientes:

Autenticación y Autorización → Implementación
MODIFICAR [Link] → Añadir Servicio de Autenticación
En entorno de desarrollo no se requiere Se almacena el token
https en las peticiones

Campos del token que serán

validados en su recepción

Se indican algunas propiedades que se usarán para

comprobar si el token es válido.
Autenticación y Autorización → Implementación
MODIFICAR [Link] → Habilitar Autenticación

Al igual que en MVC, tendremos que habilitar las opciones de autenticación a

la app construida.

NOTA: Es importante que se habilite la autenticación antes de la autorización,

al igual que hicimos en MVC.
Autenticación y Autorización → Implementación
CREAR CONTROLADOR DE AUTENTICACIÓN

Dado que tenemos que manejar el proceso de autenticación en nuestra API,

para controlar los identificaciones y registros, tendremos que crear un
controlador, que llamaremos AuthController.

Este será un controlador de API en blanco.

Este controlador tendrá dos acciones bien definidas:

● Login: Tomará los datos recibidos (usuario y contraseña) y tras validar que
el usuario existe y la contraseña es correcta, generaremos un token que
enviaremos al cliente.
● Register: Tomará los datos de registro y creará un usuario. Esta acción
podría generar y devolver un token, o solo retornar un 201.
Autenticación y Autorización → Implementación
CREAR CONTROLADOR DE AUTENTICACIÓN - Register
El proceso de creación de un usuario es similar a como se crean en un proyecto
MVC.
Para crear este tipo de acción se realizará lo siguiente:
● Crear una acción de tipo POST que reciba email y password por parámetro.
● Verificar que se reciben los parametros esperados.
● Crear un nuevo usuario de tipo IdentityUser, inicializando los campos
“UserName” y “Email” con el email recibido.
● Mediante el elemento UserManager, invocar a su método “CreateAsync”
pasándole por parámetro el usuario generado en el paso anterior y el password
recibido.
● En caso de trabajar con Roles, asignar un rol al usuario creado de la misma
forma que se hizo en MVC
● Retornar token generado o una llamada al método Ok.
Autenticación y Autorización → Implementación
CREAR CONTROLADOR DE AUTENTICACIÓN - Login
Para autenticar a un usuario, se tendrán que realizar lo siguiente:
● Crear una acción de tipo POST que reciba email y password.
● Verificar que los parámetros de la acción han recibido valores.
● Recuperar el usuario de la BD mediante la clase de contexto o
UserManager.
● Comprobar que el password recibido es el adecuado para el usuario
recuperado, mediante el método “CheckPAsswordAsync” de
UserManager.
● Generar una lista de Claims con los campos que queramos poner. Si
queremos Autorizar por roles, tendremos que incluir los roles en los
claims.
● Generar el token con todo lo que se necesita, como en el siguiente
ejemplo:
Autenticación y Autorización → Implementación
CREAR CONTROLADOR DE AUTENTICACIÓN - Login
Ejercicio 3
Partiendo del proyecto generado en el Ejercicio 2, realizar las siguientes
acciones:

● Incluir los paquetes de Identity necesarios para poder crear usuarios y

roles.
● Modificar la clase de contexto para sembrar un usuario.
● Crear una controlador AuthController con una acción Login para autenticar
usuarios y generar el token correspondiente que será retornado. Esto
conlleva:
○ Incluir paquetes Nuget necesarios para utilizar tokens JWT
○ Modificar el archivo de configuración
○ Modificar [Link] para incluir el servicio de autenticación basado en JWT
● Solicitar autorización para poder recuperar géneros o juegos, de forma
que solo lo puedan recuperar usuarios autenticados.
Ejercicio 3
● Incluir en AuthController otra acción Register para permitir el registro de
nuevos usuarios.

Una vez conseguido todo lo anterior, realizar las modificaciones necesarias

para incluir Roles de usuario y poder autorizar el acceso a ciertos recursos en
función del rol de usuario.