これはまだ取り組んでいますか?
@bigblind最近実装されました。
ただし、この問題は、JWTトークンRFCが完成するまで開いたままにする必要があります。
@thedrowこれが実装されている場合、その使用方法に関するドキュメントはありますか? RTDは単にここを指しており、ソースコードの何も私に飛び出していないようです。
標準がまだ完成していないため、現在ドキュメントはありません。
私が間違えない限り、標準は完成しているようです: https :
これは現在提案されている標準であり、最終化されていることを意味します。 予期しないことが起こらない限り、今後数か月で確定します。 実装を開始できると言っても過言ではありません。 ボランティアはいますか?
こんにちは@thedrow 、それが実装されているjwt、それは大丈夫ですか?、それを使用するdjangoプロバイダーが存在するかどうか知っていますか?、ありがとう。
@Antherkiv現在の実装は、仕様の4番目のドラフトに準拠しています。 誰かが現在の最終的な仕様でそれをスピードアップする必要があります。
私はそれを使用しているDjangoプロバイダーを知りません。
少し混乱しているようです。 私はここで、_server_が実装されたと人々が信じていることを読んでいます。 クライアントが表示されます: ServiceApplicationClient 。 サーバーが実際に実装されている場合、誰かが私にそれを指摘しますか?
@clintonbあなたが正しいようです。 サーバーは実装されていません。
これについて何か作業はありますか?
今のところこの機能は必要ないので、必要ありません。
必要な場合は、お気軽にPRを発行してください。
私たちは間違いなくこの機能を使用することができます。 これは他の人にも役立ちますか?
待って、それはすでにサポートされていませんか? signed_token_generatorはjwtを使用し、このジェネレーターをサーバーに渡す必要があり
この問題がJWTを使用してoauth2アクセストークンを要求することなのか、それともaccess_tokenとしてJWTトークンを生成することなのか、私にはよくわかりません。以前のコメントは後者の場合について言及していました...
JWT / RFC7519サポートが追加されていることを確認することに深く興味があり、機能していないように見えるので、できるだけ早く追加されるようにするために必要なことは何でもしたいと思います。
これが私の現在の個人的および専門的なクリティカルパスです。
「寄稿者ガイド」がソースにチェックインされているのを見ませんでした。 私の現在のニーズはJWTを非常にターゲットにしており、ドキュメントはすべてここでこれを追跡すると言っているので、ここで尋ねます。
初期の調査に基づくと、JWTのサポートは、使用されるRequestValidatorの実装と、トークン作成のための2つのメソッドの注入に関するものである可能性があります。
そうでない場合、それは少なくともoauthlibアーキテクチャの現在の目標ですか?
コードを一目見ただけで、#488がJWTトークンの生成と検証に必要なフックポイントのほとんど/すべてを追加したように見えます。 (テストされていない心ですが、それは有望に見えます)
最大の問題は、フックが何らかの形で使用されていない場合、過去のマージのようにフックが私たちを噛まないことを確認するためのテストを追加することです。
将来のマージの一環として、ポジティブおよびネガティブのテストベースを要求する必要があります。
更新:この問題によって提示された最初の問題は正しくなく、リンクされているリンクが無効であり、RFCが先行しているため、OPリンクを編集して、混乱を軽減するためにそれを反映する必要があります。古いデータにリンクしているので、ib-lundgren。
正しいRFC:
クライアント認証と承認の付与のためのJWTプロファイルについて最初に議論していた( Docs / Grants / JWTを参照)が、現在実装されているJWTトークンに分岐したこの長年の問題を解決します( Docs / Tokens / BearerでJWTトークンを使用する方法を参照してください
最も参考になるコメント
私たちは間違いなくこの機能を使用することができます。 これは他の人にも役立ちますか?