oauth-2.0 - implementar - oauth2 token

¿Cómo las bibliotecas JS del lado del cliente para OAuth2 mantienen la autenticación segura?

Question

Soy nuevo en OAuth2 y hay un problema con el que he estado luchando y, a pesar de la investigación, todavía no puedo entenderlo.

La dificultad de tener un cliente JS para OAuth2 es que no puede almacenar el secreto del cliente, ya que será ampliamente accesible en el navegador. Es decir, en esta pregunta SO, el comentario más alto dice:

"¡Creo que los parámetros tokenSecret y consumerSekret deben ser secretos! ¡¡¿Cómo pueden permanecer secretos cuando se descargan en el navegador ?!"

Por lo tanto, ¿cómo los marcos OAuth2 del lado del cliente como hello.js o oauth.io superan este problema? Sé que usan un proxy del lado del servidor (que conoce el ID y el secreto) para sus solicitudes, pero el código JS del cliente todavía necesita decirle al proxy quién es. Entonces, ¿qué impide a alguien tomar el código JS de mi sitio web y hablar con el proxy en mi nombre?

También he encontrado la API de Google API para JavaScript . AFAIK allí el código del cliente no pasa un secreto. ¿Entiendo correctamente que administran esto al tener una dirección de respuesta OAuth predefinida? (para que los tokens siempre se devuelvan a través de una dirección HTTP predefinida). Entonces, ¿incluso si alguien intenta suplantar mi sitio web utilizando mi ID, los tokens seguirán siendo devueltos a mi sitio web?

Tal vez estoy confundiendo algunos temas diferentes aquí, cualquier luz sobre el tema sería apreciada.

Answer 1

En el caso de un cliente JS, Google valida que el origen de JS coincida con el registrado con el ID del cliente. Entonces, si alguien usa el ID de cliente de otra persona, a lo sumo puede obtener un token solo para las cuentas que posee (lo que no va a ser muy útil).

En general, nunca puede saber quién / qué cliente (o código) está hablando con su servidor. Solo se ven los datos que envían. Entonces, si otros clientes / códigos envían los mismos paquetes, no hay nada que puedas hacer y, en general, no deberías preocuparte. Debes preocuparte de que tengas las credenciales adecuadas en la solicitud.

Answer 2

Toda la confusión está relacionada con los parámetros que tenemos que pasar para obtener el token de acceso. He hecho un pequeño código lib. @ git puedes comprobarlo.

https://github.com/dev-sandeep/oauth-js

var deferred = jQuery.ajax({
url: '''',//Access URL goes here
method: ''POST'',
dataType: ''text'',
data: {
scope: scope, //your scope
client_id: clientId,//client id
client_secret: clientSecretId,//client secret id
grant_type: ''client_credentials''
},
headers: {
''Accept'': ''application/json, application/x-www-form-urlencoded'',
''Content-Type'': ''application/x-www-form-urlencoded'',
},
complete: function (xhr, data) {
/* YOUR WORK STARTS HERE! */
console.warn(xhr, data);
}
});

Answer 3

Hay flujos en OAuth2 que no requieren un secreto (por ejemplo, el flujo implicit se usa normalmente para clientes basados ​​en JS, SPA, etc.). Sin embargo, no todos los proveedores admiten este flujo, por lo que, en esas situaciones, necesita un componente del lado del servidor que lo negocie por usted y luego maneje las interacciones con su front-end / dispositivo.

En cualquier caso, necesita que el usuario se autentique. El secret autentica al cliente (su aplicación), no al usuario. La URL de retorno (o devolución de llamada) protege el token para que se publique en otro lugar (solo su aplicación).

Las muestras de estos flujos están aquí: https://docs.auth0.com/protocols#5

Actualización: hay un protocolo específico de intercambio de código / token para "clientes públicos" que agrega seguridad adicional: PKCE (cómo funciona es aquí: https://auth0.com/docs/protocols#oauth2-pkce-for-public-clients )