Ya existen varias soluciones estándar para este tipo de problema, como Javascript Web Tokens. La arquitectura para la mayoría de estas soluciones es bastante sencilla: tiene un servicio de autenticación que autentica al usuario y devuelve un token único que está cifrado y contiene información que su servicio requiere. El servidor posee la clave privada para este token. Luego, su cliente hace llamadas a la API y pasa el token como un parámetro en la llamada a la API. El servicio utiliza la clave privada para verificar el token y posiblemente extraiga detalles adicionales del toekn para verificar la autorización, etc. A menudo, el token tendrá una fecha de caducidad así como otros datos. La cantidad de estos datos adicionales dependerá de su aplicación y de los requisitos que tenga. El componente crítico es garantizar que su clave privada utilizada para cifrar el token sea segura.
También es importante asegurarse de que cualquier solución que adopte se ajuste a su aplicación. El nivel de seguridad que necesita dependerá de su evaluación de riesgos y de la medida en que las cosas deben protegerse. No hay nada peor para el usuario que tener que pasar por demasiada seguridad en comparación con el valor del servicio que se ofrece.
También recomendaría usar una solución existente, bien probada y entendida en lugar de intentar reinventar la rueda. Hay una serie de bibliotecas tanto para servidores como para clientes que manejan este tipo de requisitos. No se garantiza que estos sean 100% seguros (nunca lo hay). Por ejemplo, ha habido publicaciones recientes relacionadas con problemas de seguridad con las bibliotecas JWT. Sin embargo, el hecho de que estos marcos se estén probando y examinando en busca de problemas de seguridad significa que probablemente obtendrá un mejor resultado final que escribir algo por su cuenta que no está recibiendo esa atención adicional.