¡Tan simple como eso!
Los clientes que no pueden mantener el secreto de client_secret en OAuth2 no tienen que usarlo.
Entonces, ¿cuál es el punto de tenerlo, si no es necesario? ¿Qué me estoy perdiendo aquí?
OAuth 2.0 admite varios tipos de concesión diferentes, y permiten que la aplicación cliente interactúe con un servidor de recursos en nombre del propietario del recurso de diferentes maneras.
El uso de una subvención implicit tiene implicaciones de seguridad, que es el tipo que no requiere un secreto de cliente. Específicamente, en este flujo de autorización, el cliente (ya que no hay un secreto de cliente) depende completamente del propietario del recurso (el usuario con el navegador, en general) para obtener, presentar y retener el token de acceso. Esto eleva significativamente el nivel requerido para proteger el token (realmente no puede tener una aplicación que dependa de este tipo de concesión que no esté completamente protegida por TLS / HTTPS) y existe un riesgo adicional de que el token sea robado y mal utilizado sin la aplicación del cliente conocimiento. Debido a estos riesgos adicionales, el RFC recomienda específicamente que no dependa de subvenciones implícitas a menos que tenga que hacerlo.
Si su aplicación tiene la capacidad de proteger adecuadamente el secreto de un cliente, se recomienda usar el tipo de concesión authorization code en su lugar. Esto permite que el flujo de autorización se administre a través de la aplicación y elimina el requisito para que el propietario del recurso maneje el proceso de autorización de forma externa y opaca para el cliente. Esto significa que el cliente también puede proteger los tokens de acceso y no necesita depender de los usuarios para mantenerlos seguros.
Por lo tanto, el secreto del cliente no es una opción extraña. Es una parte integral de la opción preferida. El tipo de subvención implict que no requiere un secreto de cliente es simplemente un último recurso para las aplicaciones cliente que no tienen la capacidad de implementar una mejor opción.
No he leído la especificación, por lo que estoy haciendo suposiciones aquí, pero podría permitirle dar soporte a los clientes básicos y diferenciarlos en función de si el cliente le envía un client_secret o no. Por ejemplo, podría imponer una regla de caducidad más estricta en el request_token que envía al cliente si no le envían un client_secret.
Los secretos privados como OAuth client_secret solo funcionan si puede confiar en la otra parte de la cadena para mantener el secreto de esa información. Entonces, esta regla significa que si el cliente no puede mantener el secreto, debería dejarlo claro al servidor al no proporcionar el client_secret. La consecuencia de esa regla es que si un cliente le envía un client_secret, significa que debe poder garantizar el secreto y puede confiar en que lo haga. Desde la perspectiva del servidor, significa que sabe si el cliente puede mantener el secreto y, por lo tanto, adaptar la política de seguridad en consecuencia. No tienes que hacerlo, pero puedes.
Lea otras preguntas en las etiquetas oauth