Oauthlib: 장치 코드 부여 유형

사양은 아직 초안 https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 이지만 누군가가 oauthlib에서 구현하기 시작하면 좋을 것입니다. PR 환영합니다

@JonathanHuot 기여자가 이 기능을 추가할 수 있는 위치에 대한 좋은 문서가 있습니까?

Gitter 채널에서 질문할 수 있습니다.

드로우가 언급했듯이 우리는 Gitter에서 매우 반응적입니다. 또한 다른 보조금을 살펴보고 현재 구현된 방식을 확인할 수 있습니다. 또한 _client_ 코드는 _server_ 코드와 다르지만 클라이언트와 서버 모두에 공통 코드가 있는 경우가 있습니다.
클라이언트 부분을 살펴보고 있다면 이상적으로는 oauthlib의 주요 "클라이언트" 다운스트림인 requests-oauthlib 에도 PR을 제안해야 합니다.

더 일반적인 내용에 대해서는 기여 페이지 https://oauthlib.readthedocs.io/en/latest/contributing.html 에서 볼 수도 있습니다.

나는 내가 작업하고 있는 프로젝트를 위해 이것을 구현해야 하기 때문에 서버 측에 더 관심이 있습니다. Atm 내 사용자 정의 코드를 사용하여 수행했지만 올바른 방법으로 수행하고 싶습니다.

토론하기 위해 gitter에 뛰어들 것입니다 :)

나는 도울 수 없지만 클라이언트 측을 떠나는 것은 나쁜 생각입니다.

클라이언트 측을 구축할 수 있지만 장치 코드 서버 자체는 여전히 많은 작업이 필요합니다.

JWT 지원이 매우 필요한 상황에서 이에 필요한 아키텍처를 생각하고 있습니다.

@duaneking 해당 변경 사항에 대해 미해결 문제가 있습니까? 논의할 수 있습니까? 변경 사항이 발생할 때까지 이 작업을 일시 중지할 수 있습니다.

@duaneking , 전체 JWT 지원에는 아키텍처가 변경될 수 있지만 @jcampbell05 가 작업을 완료하는 것을 방해해서는 안됩니다. 장치 흐름은 JWT와 아무 관련이 없으며 JWT 새 아키텍처와 충돌하지 않아야 합니다.
_EDIT:_ JWT 새 아키텍처가 많은 리팩토링을 의미하는 경우 이 DeviceFlow를 완료하고 DeviceFlow가 완료되면 JWT 리팩토링을 수행하는 것을 선호합니다. 아무도 이 리팩토링 논의를 시작하지 않았고 DeviceFlow보다 완료되지 않았기 때문입니다.

클라이언트 측에서는 1차 PR 때 구현하면 정말 좋을 것 같아요. 또한 Device Flow 구현 자체를 테스트하는 데 도움이 됩니다.

@JonathanHuot 그래서 나는 기본적으로 어쨌든 그것을 테스트하기 위해 내 자신의 클라이언트를 작성하고 있는 클라이언트에 대해 생각하고 있으므로 이 라이브러리에서 구현하는 것도 나쁘지 않을 것이라고 생각합니다.

내 가장 큰 반발은 기능을 절반만 수행하는 것이었습니다. 클라이언트를 추가하면 이 문제가 해결됩니다. 감사 해요.

지금은 이 작업을 완료할 수 있는 대역폭이 없습니다. 누군가 이 작업을 수행하거나 나중에 다시 시작할 수 있기를 바랍니다.

초안에 더 이상 없습니다 https://tools.ietf.org/html/rfc8628