Oauthlib: Tipo de concesión de código de dispositivo

La especificación todavía está en borrador https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 , pero sería excelente si alguien comenzara a implementarla en oauthlib. Los PR son bienvenidos

@JonathanHuot , ¿existe una buena documentación sobre dónde los contribuyentes pueden comenzar a agregar esta función?

Puedes preguntar en nuestro canal de Gitter.

Como lo mencionan los drow, somos muy reactivos en Gitter. También puede echar un vistazo a las otras subvenciones y ver cómo se implementan actualmente. También tenga en cuenta que estamos diferenciando el código _cliente_ del código _servidor_, pero en algún momento tenemos un código común tanto para el cliente como para el servidor.
Si está investigando la parte del cliente, idealmente, también debería proponer un PR a requests-oauthlib que es el "cliente" principal aguas abajo de oauthlib.

También puede echar un vistazo a nuestra página de contribuciones https://oauthlib.readthedocs.io/en/latest/contributing.html para obtener más información genérica.

Estoy más interesado en el lado del servidor ya que necesito implementar esto para un proyecto en el que estoy trabajando. Atm Lo he hecho usando mi código personalizado, pero tengo muchas ganas de hacerlo de la manera correcta.

Saltará sobre gitter para discutir :)

No puedo evitar sentir que dejar de lado al cliente es una mala idea.

Puedo construir el lado del cliente, pero el servidor de código del dispositivo en sí sigue siendo un gran trabajo

Solo estoy pensando en la arquitectura necesaria para esto en el contexto del soporte JWT MUY necesario.

@duaneking , ¿tenemos un problema abierto para ese cambio, tal vez podamos discutirlo? Puedo pausar este trabajo hasta que ese cambio haya ocurrido.

@duaneking , el soporte completo de JWT puede tener cambios en la arquitectura, pero no debería evitar que @jcampbell05 complete su trabajo. Device Flow no tiene nada que ver con JWT y no debería estar en conflicto con la nueva arquitectura de JWT.
_EDITAR:_ Si la nueva arquitectura de JWT implica una gran cantidad de refactorización, preferiré completar este DeviceFlow y hacer la refactorización de JWT una vez que DeviceFlow haya terminado. Solo porque nadie ha iniciado esta discusión de refactorización y está lejos de completarse que DeviceFlow.

Del lado del cliente, si se implementa durante la primera RP, sería genial, lo confieso. Además, ayuda a probar la propia implementación de Device Flow.

@JonathanHuot , así que he estado pensando en el cliente. Básicamente, estoy escribiendo mi propio cliente para probarlo de todos modos, así que supongo que tampoco estará de más implementarlo en esta biblioteca.

Mi mayor rechazo fue que las funciones estuvieran a medio hacer; Si está agregando un cliente, eso resuelve esto. Gracias.

No tengo ancho de banda para terminar esto en este momento, así que espero que alguien pueda retomar esto o tal vez pueda reanudarlo más tarde.

No más en borrador https://tools.ietf.org/html/rfc8628