Oauthlib: デバイスコード付与タイプ

仕様はまだドラフトhttps://tools.ietf.org/html/draft-ietf-oauth-device-flow-13にありますが、誰かがoauthlibに実装し始めれば素晴らしいでしょう。 PRは大歓迎です

@JonathanHuotは、寄稿者がこの機能を追加し始めることができる場所に関する優れたドキュメントがありますか？

あなたは私たちのGitterチャンネルで尋ねることができます。

drowが言及しているように、私たちは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よりも完成にはほど遠いからです。

クライアント側については、最初のPRで実施すれば、それは素晴らしいことだと私は告白します。 また、デバイスフローの実装自体をテストするのにも役立ちます。

@JonathanHuotなので、私は基本的に自分のクライアントを作成してテストするクライアントについて考えていたので、このライブラリに実装しても問題はないと思います。

私の最大の反発は、機能を半分完成させることでした。 クライアントを追加する場合は、これで解決します。 ありがとうございます。

現在、これを完了するための帯域幅がありません。誰かがこれを手に入れることができるか、後で再開できることを願っています。

ドラフトはもうありませんhttps://tools.ietf.org/html/rfc8628