Chapters

37 Chapters | 3:43:31 |

01

¿Documentos API en producción?

8:22
02

¿Token API? ¿Cookies de sesión?

8:07
03

Formulario de inicio de sesión API con json_login

5:36
04

Manejo de errores de autenticación

3:47
05

En Autenticación correcta

6:03
06

Cerrar sesión y pasar datos de la API a JavaScript

5:45
07

Pasar valores a Stimulus

4:32
08

Tipos de token y la entidad ApiToken

5:59
09

Generar el token de la API y los accesorios

5:58
10

Autenticador de token de acceso

8:56
11

Personalizar los documentos de OpenAPI

7:31
12

Ámbitos de los tokens de la API

5:51
13

Denegar el acceso con la opción "seguridad

7:11
14

Poner en marcha un sistema de pruebas asesino

8:18
15

Aserciones de la prueba JSON y siembra de la base de datos

3:41
16

Aserciones de prueba JSON avanzadas y flexibles

4:04
17

Probar la autenticación

4:59
18

Personalizar el navegador globalmente

3:50
19

Probar la autenticación por token

3:24
20

Nuevo comportamiento PUT

4:46
21

Permitir editar sólo a los propietarios

7:49
22

Permitir que los usuarios administradores editen cualquier tesoro

4:11
23

Votante de seguridad

6:13
24

Campos condicionales por usuario: ApiProperty

5:13
25

Prueba de Usuario + Contraseña Simple

4:21
26

Procesadores de Estado: Hashing de la contraseña de usuario

6:55
27

Grupos de validación y formatos de parche

8:01
28

Grupos Dinámicos: Creador de Contextos

8:26
29

Normalizador personalizado

5:08
30

Decoración del normalizador y "Normalizer Aware" (consciente del normalizador)

6:29
31

Campos totalmente personalizados

3:24
32

Validador personalizado

7:58
33

Validar cómo cambian los valores

8:30
34

Configuración automática del "propietario

4:19
35

Extensión de consulta: Autofiltrar una colección

6:15
36

404 En Artículos No Publicados

8:00
37

Filtrar la colección de relaciones

5:39

> APIs > API Platform 3: Seguridad para tus tesoros

Buy Access to Course

02.

¿Token API? ¿Cookies de sesión?

Autoplay

Previous Chapter

Next Chapter

Acompáñame mientras contamos una historia tan antigua como... la Internet moderna: La autenticación de API. Un tema de bombo y platillo, complejidad y héroes improbables. Los personajes incluyen sesiones, tokens de API, OAuth, ¡tokens web JSON! Pero, ¿qué necesitamos para nuestra situación?

Lo primero que quiero que te preguntes es

¿Quién va a utilizar mi API?

¿Es tu propio JavaScript, o necesitas permitir el acceso programático? ¿Como si alguien fuera a escribir un script que utilizara tu API?

Vamos a repasar estos dos casos de uso... y cada uno tiene algunas complejidades adicionales que discutiremos por el camino.

¡Todo es un Token!

Por cierto, cuando piensas en la autenticación de una API, sueles pensar en un token de API, ¡y es cierto! Pero resulta que... prácticamente toda la autenticación se realiza mediante algún tipo de token. Incluso la autenticación basada en sesión se realiza enviando una cookie... que contiene un único, lo has adivinado, "token". Es una cadena aleatoria que PHP utiliza para encontrar y cargar los datos de sesión relacionados en el servidor.

Así que el truco está en averiguar qué tipo de token necesitas en cada situación y cómo lo obtendrá el usuario final.

Caso 1: Construir para tu propio JavaScript

Hablemos del primer caso de uso: el usuario de tu API es tu propio JavaScript.

Bien, antes de que nos sumerjamos en la seguridad, asegúrate de que tu frontend y tu API viven en el mismo dominio... exactamente en el mismo dominio, no sólo en un subdominio. ¿Por qué? Porque si viven en dos dominios o subdominios diferentes, tendrás que lidiar con CORS: Intercambio de Recursos entre Orígenes.

CORS no sólo añade complejidad a tu configuración, sino que también perjudica al rendimiento. Kévin Dunglas -el desarrollador principal de API Platform- tiene una entrada de blog sobre esto. Incluso muestra una estrategia en la que tu frontend y tu backend pueden vivir en directorios o repositorios totalmente distintos, pero seguir viviendo en el mismo dominio gracias a algunos trucos del servidor web.

Si, por alguna razón, decides poner tu API y tu frontend en subdominios diferentes, entonces tendrás que preocuparte de las cabeceras CORS y puedes solucionarlo con NelmioCorsBundle. Pero no te lo recomiendo.

El caso de las Sesiones

De todos modos, volvamos a la seguridad. Si estás llamando a tu API desde tu propio JavaScript, es probable que el usuario se esté registrando a través de un formulario de acceso con un correo electrónico y una contraseña. No importa si se trata de un formulario de inicio de sesión tradicional o de uno creado con un sofisticado framework JavaScript que se envía mediante AJAX.

Y, sinceramente, una forma muy sencilla de gestionar este caso de uso no es con tokens de API, sino con la autenticación básica HTTP de toda la vida. Es decir, pasando literalmente el correo electrónico y la contraseña a cada ruta. Por ejemplo, el usuario introduce su correo electrónico y contraseña, tú haces una petición API a algún punto final sólo para asegurarte de que es válido, luego almacenas ese correo electrónico y contraseña en JavaScript y lo envías en cada petición API que se realice en adelante. Tu correo electrónico y contraseña funcionan básicamente como un token API.

Sin embargo, esto tiene algunos retos prácticos, como la cuestión de dónde almacenas de forma segura el correo electrónico y la contraseña en JavaScript para poder utilizarlos continuamente. En realidad, éste es un problema en general con JavaScript y las "credenciales", incluidos los tokens de API: tienes que tener mucho cuidado con dónde los almacenas para que otro JavaScript de tu página no pueda leerlos. Hay soluciones: https://bit.ly/auth0-token-storage - pero añade una complejidad que muy probablemente no necesites.

Así que en su lugar, para tu propio JavaScript, puedes utilizar una sesión. Cuando inicias una sesión en Symfony, devuelve una cookie "sólo HTTP"... y esa cookie contiene el id de sesión. Aunque, el contenido de la cookie no es realmente importante: puede ser el id de sesión o algún tipo de token que hayas inventado y estés leyendo en Symfony. Lo realmente importante es que, como la cookie es "sólo HTTP", no puede ser leída por JavaScript: ni por tu JavaScript ni por el de nadie. Pero siempre que realices una petición a la API de tu dominio, esa cookie vendrá con ella... y tu aplicación la utilizará para iniciar la sesión del usuario.

Así que el token de la API en esta situación es simplemente el "identificador de sesión", que se almacena de forma segura en una cookie sólo HTTP. Mmmm. Vamos a codificar este caso de uso.

Ah, y por cierto, un caso extremo en esta situación es si tienes una situación de Inicio de Sesión Único - un SSO. En ese caso, te autenticarás con tu SSO como una aplicación web normal. Cuando termines, tendrás un token, que puedes utilizar para autenticar al usuario con una sesión normal... o puedes utilizar ese token directamente desde tu JavaScript. Se trata de un caso de uso más avanzado que no trataremos en este tutorial... aunque sí hablaremos de cómo leer y validar los tokens de la API, independientemente de su procedencia.

Caso de uso 2: Acceso programático y tokens de API

El segundo gran caso de uso de la autenticación es el acceso programático. Algún código hablará con tu API... además de JavaScript desde dentro del navegador.

En este caso, los clientes de la API enviarán absolutamente algún tipo de cadena de token de la API, por lo que tienes que hacer que tu API pueda leer un token que se envía en cada petición, normalmente en una cabecera Authorization:

$response = $thhpClient->request(
    'GET',
    '/api/treasures',
    [
        'Authorization' => 'Bearer '.$apiToken,
    ],
);

Cómo obtiene el usuario este token depende: hay dos casos principales. El primero es el caso del "token de acceso personal a GitHub". En este caso, un usuario puede ir a una página de tu sitio y hacer clic para crear un nuevo token de acceso. Luego puede copiarlo y utilizarlo en algún código.

El segundo gran caso es OAuth, que no es más que una forma elegante y segura de obtener un token de acceso. Es especialmente importante cuando el "código" que realiza las peticiones a la API lo hace en "nombre" de algún usuario de tu sistema.

Por ejemplo, imagina un sitio -R ReplyToAllCommentsWithHearts.com- que te permite conectarte con GitHub. Una vez lo hayas hecho, ese sitio puede hacer peticiones de API a GitHub para tu cuenta, como hacer comentarios como tu usuario. O imagina una aplicación para iPhone en la que, para iniciar sesión, muestres al usuario el formulario de inicio de sesión de tu sitio. Entonces, a través de un flujo OAuth, esa aplicación móvil recibirá un token de acceso que podrá utilizar para hablar con tu API en nombre de ese usuario.

En este tutorial vamos a hablar del método del token de acceso personal, incluyendo cómo leer y validar los tokens de la API, vengan de donde vengan. No hablaremos del flujo OAuth... y en parte es porque es una bestia aparte. Sí, si tienes un caso de uso en el que necesitas permitir que terceros obtengan tokens de API para diferentes usuarios de tu sitio, necesitarás algún tipo de servidor OAuth, tanto si lo construyes tú mismo como si utilizas alguna otra solución. Pero una vez que el servidor OAuth ha hecho su trabajo, el cliente que hablará con tu API recibe... ¡un token! Y luego utilizarán ese token para hablar con tu API. Así que tu API tendrá que leer, validar y entender ese token, pero no le importa cómo lo obtuvo el cliente de la API.

Bien, dejemos atrás toda esta teoría y empecemos a repasar a continuación el primer caso de uso: permitir que nuestro JavaScript inicie sesión enviando una petición AJAX.

9 Comments

Sort By

Sebastian-K 1 year ago

Hi, it's me again. Asking questions here and there 😅. I am not sure if this is the correct topic for my question, but its about authorization, so:

We are building an app where the user can work on different projects, so depending on the selected project, we automatically inject the right project IRI to every request as a filter. There is also a automatic condition in my backend repository like project in (:allValid) for item and collection

This works fine, but we need the user to have different roles depending on the project. We have a ProjectUser entity with project, user and roles and I plan to somehow inject the roles on authentication into my user and then everything afterwards works like before (iE Security voters)

But this implies that I need exactly one project (so no more filter for the current project) because I need to find exactly one ProjectUser so I am thinking about saving the current project in the session (will be set on login and by custom route to switch).

I know how to save it into the session but not how to inject the roles into my user depending on the selected project.

Is this the right approach?

| Reply |

weaverryan SFCASTS Sebastian-K 1 year ago

Hey @Sebastian-K!

Hmmm, very interesting situation! Ok, so typically (as you know), we read the roles from the User object. This means that, once the user logs in, the roles are static throughout the rest of that user's session. Your situation is a bit different, if I understand it, because the user could switch the project, which would change the roles for that user. There are two approaches I can think of, and I'm not positive which will be better :)

A) Try to "change" the roles on the user when the project is selected/changed. In reality, when the user authenticates, the "roles" are stored on the "token". The roles for the token are populated from User::getRoles() (https://github.com/symfony/symfony/blob/6.4/src/Symfony/Component/Security/Http/Authenticator/AbstractAuthenticator.php#L31) but ultimately, the final roles live on the token - and that's what matters for authorization.

Specifically, the RoleVoter calls $token->getRoleNames() during authorization to figure out what roles the currently-authenticated user has - https://github.com/symfony/symfony/blob/6.4/src/Symfony/Component/Security/Core/Authorization/Voter/RoleVoter.php#L66

So, in theory, you could create your own, custom token class (that likely extends AbstractToken) and give this a method like setRoles() where you can override the current roles. To allow this to be used, you would need to extend / hook into whatever your authentication "authenticator" is and create your custom token object instead of the default one: https://github.com/symfony/symfony/blob/6.4/src/Symfony/Component/Security/Http/Authenticator/AbstractAuthenticator.php#L29-L32

Then, when the user changes projects, you could set the new roles onto your token using that ->setRoles() method. Since it sounds like you're using session-based authentication, the updated token with the updated roles would get serialized into the session at the end of that request and used on the future requests.

B) The other approach would be to do nothing special with the token or trying to make the roles dynamic. In this case, instead of protecting your app with roles like ROLE_EDITOR, you would create some new prefix for project-related roles and use things like PROJECT_EDITOR. You would then create a custom voter for this, which would look at the current project and see if the user has this "role". This solution is a bit simpler.

Cheers!

| Reply |

Pierre-A 1 year ago

Hello Ryan, another little typo error in your code here :

$response = $thhpClient->request( // This should be httpClient !!!
    'GET',
    '/api/treasures',
    [
        'Authorization' => 'Bearer '.$apiToken,
    ],
);

or someone invented a new protocole: thhp i didn't know ? ;) ... many thanks for tutos !

| Reply |

MolloKhan SFCASTS Pierre-A 1 year ago edited

Lol - thank you @Pierre-A

| Reply |

laferte_tech 1 year ago

Hello Ryan,
Thanks for this tutorial.
Like Ugo, I am also a bit confused but by another another point.
When you say "Or imagine an iPhone app where, to log in, you show the user the login form on your site. Then, via an OAuth flow, that mobile app will receive an access token it can use to talk to your API on behalf of that user."
Why do we need OAuth here ?
They state the same thing on the link you gave (auth0.net) : "If the Application is a native app, then use the Authorization Code Flow with Proof Key for Code Exchange (PKCE)."

I was thinking it was possible to just use JWT to authenticate for a native app. For example, let's take Flutter, we can use the secure storage (https://pub.dev/packages/flutter_secure_storage) to store the JWT, right ? So is there something wrong with sending my email+password to my api endpoint (like in normal spa), then read the answer, store the token in the safe place and then re-use for latter requests by adding this token to the Authorization header (i saw this implementation in few places also). I can also use this token, to display connected / not connected page depending if token is valid or not (by checking from time to time).

But since it's seem mandatory to use Oauth with PKCE, i think i'm missing something about the security but i don't see what :-)
If you can help on this subject, it would be very nice.
Thanks a lot.

| Reply |

weaverryan SFCASTS laferte_tech 1 year ago

Hey @Romain-L!

Sorry for the slow reply - just got back from vacation :).

Yea.. this stuff is SO tricky - and I'm not an expert on every aspect for sure!

I was thinking it was possible to just use JWT to authenticate for a native app. For example, let's take Flutter, we can use the secure storage (https://pub.dev/packages/flutter_secure_storage) to store the JWT, right ?

Yes, I'm 99% sure that this will "work". And, about storage, I don't know what the normal solution is for this, but even with OAuth, after you complete the process, you'll need to store the access token somewhere. So storing an access token or JWT is a legitimate thing to do.

So is there something wrong with sending my email+password to my api endpoint (like in normal spa), then read the answer, store the token in the safe place and then re-use for latter requests by adding this token to the Authorization header (i saw this implementation in few places also).

I'm not an expert here, but yes, I think this is "fine". What you're seeing is that OAuth is recommended because it's a standard, so there's less risk that you mess something up. Additionally, with OAuth, the user ultimately enters their email/password into a browser with your site's URL in the address bar. With your solution, you enter it directly into the app... which can be a risk (assuming your users are smart enough to notice) because a "bad user" could create an app that looks like your app with a login form... which then sends their credentials somewhere else. So by using OAuth, you can increase the user's trust. But in reality, I'm not sure how many users will actually do this.

Here's another document from Auth0 that talks in more depth about this topic - https://auth0.com/docs/get-started/authentication-and-authorization-flow/mobile-device-login-flow-best-practices

Cheers!

1 | Reply |

laferte_tech weaverryan 1 year ago

Hello Ryan,
Thank you very much for your time and your answer. It's more clear to me know. So i will go with the "basic" solution since it's seems to be ok. I checked a few mobile apps and they all allow to enter email/pwd in the app without oauth for there own users, so let's go for this!
Thanks and have a nice day

| Reply |

Ugo 1 year ago

Hi Ryan,
I am getting a bit confused..
I am developing a backoffice+api in Symfony and a front end app in vuejs/nuxt. The front end app will be used only by external users that will have to login to get their own data (authentication + authorisation). These two apps have separate repo and I was planning to use two different subdomains (ex: backoffice.myurl.com and myurl.com) and sessions. I am now getting confused with what you explained about CORS. Is anything wrong with my setup ?
thx for your help

| Reply |

weaverryan SFCASTS Ugo 1 year ago

Hi Ugo!

Excellent question! Because you're using sessions, there are 2 things to think about:

1) Can your frontend and backend share a session? The answer is yes. And it will likely happen automatically. When you send a POST request to myurl.com (your API) to authenticate, and then your API creates a session, it will probably create the SameSite session cookie under the domain myurl.com. Because backoffice.myurl.com is a subdomain of that, it can use that cookie. So, all good here ✅

2) Can your frontend JavaScript make Ajax requests to your API? The answer is "yes", "but". You WILL be able to do this. However, your frontend will first make a CORS preflight request basically asking your API if it's ok if backoffice.myurl.com makes Ajax calls to it. So, to get this to work, you'll need to configure some CORS config on your API to say that requests coming from backoffice.myurl.com are "allowed". But, you'll STILL have s flight performance impact because your frontend will first need to make that extra "preflight" request before it makes the real AJAX request. I'm not an expert on CORS, but it looks like you can set a header - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age - so that this preflight request is not made often.

So, CORS is the problem. Your setup will work, but you'll need some CORS config and you'll suffer (slightly) from that preflight request. The alternative, which Kévin Dunglas talks about - https://dunglas.dev/2022/01/preventing-cors-preflight-requests-using-content-negotiation/ - is to just use something like myurl.com/backoffice and then configure your webserver to serve the /backoffice URL from the totally different frontend app code :).

Cheers!

| Reply |

API Platform 3 Symfony 6.2

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.1",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "api-platform/core": "^3.0", // v3.1.2
        "doctrine/annotations": "^2.0", // 2.0.1
        "doctrine/doctrine-bundle": "^2.8", // 2.8.3
        "doctrine/doctrine-migrations-bundle": "^3.2", // 3.2.2
        "doctrine/orm": "^2.14", // 2.14.1
        "nelmio/cors-bundle": "^2.2", // 2.2.0
        "nesbot/carbon": "^2.64", // 2.66.0
        "phpdocumentor/reflection-docblock": "^5.3", // 5.3.0
        "phpstan/phpdoc-parser": "^1.15", // 1.16.1
        "symfony/asset": "6.2.*", // v6.2.5
        "symfony/console": "6.2.*", // v6.2.5
        "symfony/dotenv": "6.2.*", // v6.2.5
        "symfony/expression-language": "6.2.*", // v6.2.5
        "symfony/flex": "^2", // v2.2.4
        "symfony/framework-bundle": "6.2.*", // v6.2.5
        "symfony/property-access": "6.2.*", // v6.2.5
        "symfony/property-info": "6.2.*", // v6.2.5
        "symfony/runtime": "6.2.*", // v6.2.5
        "symfony/security-bundle": "6.2.*", // v6.2.6
        "symfony/serializer": "6.2.*", // v6.2.5
        "symfony/twig-bundle": "6.2.*", // v6.2.5
        "symfony/ux-react": "^2.6", // v2.7.1
        "symfony/ux-vue": "^2.7", // v2.7.1
        "symfony/validator": "6.2.*", // v6.2.5
        "symfony/webpack-encore-bundle": "^1.16", // v1.16.1
        "symfony/yaml": "6.2.*" // v6.2.5
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.2
        "mtdowling/jmespath.php": "^2.6", // 2.6.1
        "phpunit/phpunit": "^9.5", // 9.6.3
        "symfony/browser-kit": "6.2.*", // v6.2.5
        "symfony/css-selector": "6.2.*", // v6.2.5
        "symfony/debug-bundle": "6.2.*", // v6.2.5
        "symfony/maker-bundle": "^1.48", // v1.48.0
        "symfony/monolog-bundle": "^3.0", // v3.8.0
        "symfony/phpunit-bridge": "^6.2", // v6.2.5
        "symfony/stopwatch": "6.2.*", // v6.2.5
        "symfony/web-profiler-bundle": "6.2.*", // v6.2.5
        "zenstruck/browser": "^1.2", // v1.2.0
        "zenstruck/foundry": "^1.26" // v1.28.0
    }
}

Previous Chapter

Next Chapter

¿Token API? ¿Cookies de sesión?

Share this awesome video!

¡Todo es un Token!

Caso 1: Construir para tu propio JavaScript

El caso de las Sesiones

Caso de uso 2: Acceso programático y tokens de API

9 Comments

Delete comment?

What PHP libraries does this tutorial use?