authentication - sesion - oauth2 token

(GitHub) Autenticación API OAuth para aplicaciones que no son de un sitio web? (1)

El comienzo de mi confusión

Estoy trabajando específicamente con GitHub, pero esto parece bastante general.

El estado de los documentos GitHub [el formateo ha sido modificado por mí]:

Hay tres formas de autenticarse a través de GitHub API v3. ...
Autenticación básica
Token OAuth2 (enviado en un encabezado)
Token OAuth2 (enviado como parámetro)
Clave OAuth2 / Secreto
... Tenga en cuenta que los tokens de OAuth2 pueden adquirirse mediante programación , para aplicaciones que no son sitios web.

[Supongo que el segundo y el tercer elemento se consideran una sola ''forma de autenticarse'' pero luego, según el formato de esa sección, el "límite de inicio de sesión fallido" también podría malinterpretarse como una ''manera de autenticarse'' como no hay una lista explícita de las "tres formas".]

El texto en el enlace "adquirido programáticamente" arriba comienza:

Si necesita un número pequeño de tokens, implementar el flujo web puede ser engorroso. En su lugar, los tokens se pueden crear utilizando la API de Autorizaciones de OAuth mediante la Autenticación básica. Para crear tokens para una aplicación OAuth particular, debe proporcionar su ID de cliente y su secreto, que se encuentran en la página de configuración de la aplicación OAuth, vinculados desde su listado de aplicaciones OAuth en GitHub. Si su aplicación OAuth tiene la intención de crear múltiples tokens para un usuario, debe usar huella digital para diferenciarlos.

Autenticación a través de autorización a través de otra forma de autenticación?

Analizando mi confusión

Analicemos todo lo anterior, frase por frase.

Primera oracion

Si necesita un número pequeño de tokens, implementar el flujo web puede ser engorroso.

Bueno, con suerte, mi increíble aplicación para no sitios web tendrá muchos usuarios, así que necesito muchos tokens, ¿no? Entonces, ¿eso significa, de inmediato, que debería estar "implementando el flujo web"? Sospecho que sí.

Segunda oración

En su lugar, los tokens se pueden crear utilizando la API de Autorizaciones de OAuth mediante la Autenticación básica.

Ahora, esto es bastante confuso. Quiero que mi aplicación no-web (NAWP) interactúe con GitHub, en nombre de mis usuarios, y me gustaría que eviten la limitación de la tasa de solicitud de la API de usuario no autenticada . Y no puedo simplemente registrar mi aplicación con GitHub e incluir mi identificación de cliente registrada y el secreto en mis solicitudes porque:

Este método solo debe usarse para llamadas de servidor a servidor. Nunca debe compartir el secreto de su cliente con nadie ni incluirlo en el código del navegador del lado del cliente.

Así que me gustaría autenticar a GitHub como, o en nombre de, el usuario que usa mi NAWP.

De modo que puedo crear un token de autenticación para acceder a la API regular de GitHub, usando una API de autorizaciones especial, pero primero tengo que autenticar usando la Autenticación básica. Estupendo. Una pregunta: ¿qué credenciales proporciono a través de la Autenticación básica para poder acceder a la API de autorizaciones? ¿Mía? ¿Una cuenta especial de GitHub solo para mi aplicación? ¿Los usuarios?

Supongo que se supone que debo usar las credenciales del usuario, y el usuario tiene que confiar en mi NAWP para olvidar rápidamente esas credenciales una vez que las use para crear un token de autenticación por sí mismo. Está bien, eso parece no ideal, pero estoy dispuesto a seguirlo por ahora.

Tercera oración

Para crear tokens para una aplicación OAuth particular, debe proporcionar su ID de cliente y su secreto, que se encuentran en la página de configuración de la aplicación OAuth, vinculados desde su listado de aplicaciones OAuth en GitHub.

Espere. WTF. Me autentico, con el nombre de usuario y la contraseña de GitHub de mi usuario (o un token, que el usuario tiene que generar ellos mismos) que podrían usar mi NAWP para siempre, especialmente si solo quiero acceder a información pública pero evitar la limitación de velocidad. , y luego mi NAWP tiene que hacer una solicitud para generar un token de OAuth haciendo una solicitud, para lo cual uno de los parámetros requeridos es ... "El secreto de cliente de la aplicación OAuth de 40 caracteres para el que se crea el token".

Eso no parece correcto.

En la primera sección de los documentos, citada en la parte superior de esta pregunta, debajo de la subsección "Clave OAuth2 / Secreto", está escrito:

Esto solo debe usarse en escenarios de servidor a servidor. No filtre el secreto de cliente de su aplicación OAuth a sus usuarios.

Además, en la subsección "Aumento del límite de velocidad no autenticado para aplicaciones OAuth" , está escrito:

Si su aplicación OAuth necesita realizar llamadas no autenticadas con un límite de velocidad más alto, puede pasar el ID de cliente y el secreto de su aplicación como parte de la cadena de consulta.
...
Este método solo debe usarse para llamadas de servidor a servidor. Nunca debe compartir el secreto de su cliente con nadie ni incluirlo en el código del navegador del lado del cliente.

¿Me estoy perdiendo de algo? Debo estar perdiendo algo. Porque, por supuesto, no hay manera de que pueda distribuir de forma segura el secreto del cliente que GitHub genera para mí en mi NAWP.

Cuarta oración

Si su aplicación OAuth tiene la intención de crear múltiples tokens para un usuario, debe usar huella digital para diferenciarlos.

Esto no es nada confuso (y no estoy siendo sarcástico). Si varios usuarios usaban una instancia individual de mi NAWP, entonces simplemente incluyo algún tipo de identificador para diferenciar entre los tokens que necesito o deseo crear; bastante simple en realidad.

Pero entender esta frase no hace nada para disipar mi confusión sobre los tres anteriores.

Una reformulación de mi confusión

Entonces, ¿es o no es posible autenticarse de forma segura en nombre de los usuarios de GitHub, usando OAuth, para un NAWP?

Supongo que no es así y que la única forma de usar OAuth de forma segura es con un código que se ejecuta en un entorno protegido por sus autores (una aplicación web).

Si adiviné mal, explique amablemente (en detalle) exactamente cómo un NAWP puede autenticarse a través de OAuth en nombre de sus usuarios.

Y si su solución implica distribuir el secreto del cliente con los archivos NAWP, al igual que la solución descrita en la publicación del blog a continuación, explique amablemente cómo eso no es un problema, especialmente dada la repetida insistencia de GitHub en sus documentos, que el secreto del cliente no debería ser compartido con todos.

Electrón. Autenticación de Outh con GitHub

Sí, estás parcialmente correcto. No es posible autenticarse de forma segura en nombre de un usuario que usa OAuth únicamente con una aplicación que no sea web. Esto se debe a que GitHub solo implementa el código de authorization_code OAuth flow.

En cambio, deberá tener un servidor web para ayudarlo a autenticar de manera segura a un usuario.

El proceso general se ve así:

Su aplicación redireccionará al usuario (o abrirá una ventana emergente) a su página web
Su servidor web redirigirá a su usuario al sitio de GitHub, comenzando el flujo de OAuth.
GitHub redireccionará a su usuario a su servidor con un código de autorización.
Su servidor manejará el intercambio de código de autorización y recuperará un token de acceso de GitHub válido.
Su servidor puede enviar el token de acceso a su aplicación no web, ya sea mediante un enlace a un esquema url personalizado (algo como app12345: // authorize? Access_token = XYZ, útil para aplicaciones móviles), o una url con un fragmento (algo así como https://example.com/oauth/github#access_token=XYZ ), que su aplicación de escritorio leerá de la cadena de URL.

Hice algo similar con esto para LinkedIn, Node.js, y una aplicación iOS si quieres ver un ejemplo rápido de un flujo similar.