El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Argumentos en contra de cobrar más por los métodos de autenticación básicos
La autenticación es una de las partes más rutinarias de usar una API, y es justo el tipo de detalle rutinario que acaba bloqueado tras un nivel de precios más a menudo de lo que debería. Algunos proveedores reservan ciertos métodos de autenticación, como HTTP Basic o el patrón de token Bearer, para los niveles de pago más altos, mientras que un nivel inferior solo admite un formato de encabezado único y específico. La diferencia de coste técnico entre validar un estilo de autenticación u otro es prácticamente nula. Lo que cambia es lo cómodo que resulta cada uno para el código existente de un cliente, algo que no tiene nada que ver con cuánto debería pagar por usar la API.
Aceptamos la clave como encabezado X-API-Key, como encabezado Authorization Bearer, con autenticación HTTP Basic usando la clave como nombre de usuario o como parámetro de consulta, en todos los hosts y sin coste extra por ninguno de ellos. El patrón que ya encaje con tu código, sea cual sea la biblioteca o la convención interna que tu equipo ya usa para otras API, muy probablemente ya está admitido, sin necesidad de reestructurar nada solo para ajustarte a un formato concreto que casualmente preferimos.
El razonamiento detrás de limitar los métodos de autenticación por nivel no tiene que ver realmente con el coste. Tiene que ver con diferenciar niveles por el simple hecho de hacerlo: encontrar funciones que reservar para el cliente que paga más, incluso funciones que no cuestan nada extra, solo porque tener más funciones bloqueadas tras un nivel superior hace que ese nivel parezca más valioso en una tabla comparativa. Los métodos de autenticación son un blanco fácil para esto porque admitir varios supone realmente poco esfuerzo para el proveedor y es realmente cómodo para el cliente, lo que convierte su limitación en una decisión puramente de monetización y no en una basada en una diferencia de coste real.
Creemos que este tipo de limitación castiga discretamente a los desarrolladores por una decisión que no tiene nada que ver con el valor que obtienen de los datos. Un equipo cuyas herramientas usan tokens Bearer por defecto no debería pagar más que un equipo cuyas herramientas usan un encabezado personalizado, cuando ambos hacen exactamente la misma consulta y reciben exactamente la misma respuesta. El valor del producto es la respuesta. El método de autenticación es fontanería, y la fontanería no debería tener un precio según qué tubería encaje con tu pared.
Aquí hay un principio más amplio que va más allá de la autenticación: las funciones que no le cuestan nada extra al proveedor no deberían convertirse en fronteras artificiales entre niveles solo porque se puede. Una estructura de niveles basada en diferencias de coste reales, como el volumen de solicitudes, es defendible. Una estructura de niveles rellenada con comodidades de bajo coste reservadas a quienes pagan más existe sobre todo para que la página de precios parezca más diferenciada de lo que realmente es el producto.