¿Existe una ventaja de seguridad al requerir una solicitud para cumplir con / api / 1234 en lugar de / api / me? Ambos obviamente tendrían tokens de acceso.
Mi conjetura es que api / 1234 es más seguro porque si alguien obtiene un token de acceso, no puede ver quién es. Deben saber a qué usuario pertenece el token.
Respuesta corta: no importa
En algunos casos, usar / api / 1234 podría ser una desventaja. Si la aplicación carece de las comprobaciones de autorización adecuadas, un usuario podría probar / api / 1235 y acceder a la cuenta de otro usuario. Este tipo de vulnerabilidad es sorprendentemente común en la práctica. / api / me es bueno porque obliga al desarrollador a obtener el ID de la sesión.
/ api / 1234 puede ser una ventaja si el ID de usuario es un secreto. Esto depende de la aplicación; generalmente con aplicaciones interactivas, los usuarios pueden ver las ID de otros usuarios. Si la identificación es realmente secreta, esto protege contra CSRF. Sin embargo, su aplicación ya debería tener protección CSRF, generalmente a través de un token en un campo oculto.
En general, si alguien obtiene un token de acceso, todas las apuestas están desactivadas. Concentre su esfuerzo de seguridad en evitar que alguien se apodere de un token.
Sí, es cierto que necesitarían una información adicional si también necesita la identificación del usuario, así que supongo que es más seguro.
Dicho esto, sospecho que si un token de acceso fue robado, es probable que la identificación del usuario también haya sido robada. Incluso si no lo fuera, si está utilizando ID secuenciales (como lo hace su ejemplo) y no GUID o algo así, podrían disparar una solicitud de /api/1 a /api/1000000 y ver si obtienen resultados positivos.
Lea otras preguntas en las etiquetas web-application authentication access-control