Diseñando una API con tokens de acceso, ¿cómo manejar las solicitudes GET?

Estoy creando una API que utilizará tokens de acceso para poder rastrear el uso entre varios departamentos y para el control de acceso. Mi plan es utilizar los verbos HTTP de manera adecuada: GETrecuperará información, POSTagregará, DELETEeliminará, etc.

Mi pregunta es, ¿cómo debo manejar los tokens de acceso en las llamadas GET?

Opcion uno:

Es proporcionar el token de acceso como parte de la cadena de consulta: /api/users/?token=ACCESSTOKEN. El problema que tengo con esto es que ACCESSTOKEN aparece en los registros del servidor. Este método también será diferente de las solicitudes POST o DELETE que tienen el token pasado a través del cuerpo.

Opción dos:

Proporcione un cuerpo a la solicitud (como lo hace en una POSTsolicitud) y uno de los parámetros es el token. Mi problema aquí es que otros desarrolladores de mi empresa me dicen que esto no es una "verdadera solicitud GET" porque estoy pasando datos. La url que llaman simplemente se ve así /api/users/y proporcionan token=ACCESSTOKENdentro del cuerpo.

Opción tres:

Deja de usar GETy obliga a todo a ser a POST. No me gusta esta idea porque para muchas de estas llamadas API, no estoy creando nuevos recursos. Simplemente estoy devolviendo datos que se encuentran detrás de una API que requiere autorización.

¿Hay una opción que me falta o que debo refinar? Me gusta la opción 2, pero soy sensible a las preocupaciones de otros desarrolladores de departamentos.

Opción 4: encabezados de autorización y RFC 6750 (token de portador)

La solución que está buscando ya se ha especificado como parte del estándar OAuth2, pero es independiente y será útil en su escenario.

https://tools.ietf.org/html/rfc6750

Todas las solicitudes del cliente pasarán un token portador (su token de acceso), y se verá como cualquier otro encabezado de solicitud para el servidor. La solicitud en sí se ve así:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Dado que es un estándar público ampliamente implementado, no tiene que preocuparse por definir el comportamiento, solo apunte a los desarrolladores del lado del cliente al RFC. También puede considerar implementar el resto del estándar OAuth2 como un servidor de recursos y un servidor de autorización , pero eso es mucho más trabajo.

¿Por qué no usas encabezados de solicitud? Esto separa los datos de autenticación / autorización de los datos significativos reales de la solicitud, y puede usarse para cualquier tipo de solicitud (el uso de un cuerpo de solicitud en un get generalmente es algo que no debe hacer).

Tener autorización en los encabezados le permite autenticar al usuario antes de analizar el cuerpo de la solicitud, lo cual es ventajoso cuando no desea que su sistema pierda tiempo analizando datos de un usuario no autorizado.