Oauthlib: Tipo de concessão do código do dispositivo

A especificação ainda está em rascunho https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 , mas será ótimo se alguém começar a implementá-la no oauthlib. PRs são bem vindos

@JonathanHuot existe uma boa documentação sobre onde os contribuidores podem começar a adicionar esse recurso?

Você pode perguntar em nosso canal Gitter.

Como os drows mencionam, somos muito reativos no Gitter. Você também pode dar uma olhada nas outras concessões e ver como elas estão sendo implementadas atualmente. Observe também que estamos diferenciando o código _client_ do código _server_, mas às vezes temos código comum para cliente e servidor.
Se você estiver analisando a parte do cliente, idealmente, você também deve propor um PR para requests-oauthlib que é o principal "cliente" a jusante do oauthlib.

Você também pode dar uma olhada em nossa página de Contribuição https://oauthlib.readthedocs.io/en/latest/contributing.html para coisas mais genéricas.

Estou mais interessado no lado do servidor, pois preciso implementar isso para um projeto em que estou trabalhando. Atm Eu fiz isso usando meu código personalizado, mas quero muito fazê-lo da maneira correta.

Vai pular no gitter para discutir :)

Eu não posso ajudar, mas sinto que deixar o lado do cliente de fora é uma má ideia.

Eu posso construir o lado do cliente, mas o próprio servidor de código do dispositivo ainda é muito trabalhoso

Estou apenas pensando na arquitetura necessária para isso no contexto do suporte JWT MUITO necessário.

@duaneking , temos um problema em aberto para essa mudança, talvez possamos discuti-lo? Posso pausar este trabalho até que essa mudança aconteça.

@duaneking , suporte completo a JWT pode ter mudanças de arquitetura, mas não deve impedir @jcampbell05 de concluir seu trabalho. O Device Flow não tem nada a ver com JWT e não deve entrar em conflito com a nova arquitetura JWT.
_EDIT:_ Se a nova arquitetura do JWT implicar em muita refatoração, prefiro completar este DeviceFlow e fazer a refatoração do JWT assim que o DeviceFlow terminar. Só porque ninguém iniciou essa discussão de refatoração e está longe de ser concluída do que o DeviceFlow.

Sobre o lado do cliente, se for implementado durante o primeiro PR, isso seria ótimo, confesso. Além disso, ajuda a testar a própria implementação do Device Flow.

@JonathanHuot , então estive pensando no cliente, estou basicamente escrevendo meu próprio cliente para testá-lo de qualquer maneira, então acho que também não fará mal implementar nesta biblioteca.

Minha maior resistência foi ter recursos pela metade; Se você estiver adicionando um cliente, isso resolverá isso. Obrigado.

Eu não tenho largura de banda para terminar isso agora - então espero que alguém possa pegar isso ou talvez eu possa retomar mais tarde

Chega de rascunho https://tools.ietf.org/html/rfc8628