プログラマーが独自のoAuthサービスを開発する際に考慮すべき技術的詳細は何ですか？

プログラマーが独自のoAuthサービスを開発する際に考慮すべき技術的詳細は何ですか？

ガイドラインを見つけようとしてきましたが、ほとんどのoAuth関連記事は、消費者の視点（つまり、他のサービスを利用する方法）として議論していることがわかりました。oAuth認可サービスとリソースサービスを使用して独自のシステムを設計したい。どのような技術的詳細に従うべきですか？

RFCを読んだことがあるかもしれませんが、読んでいない場合に備えて、RFCを開始する場所です。

1. oAuth 2.0「コア」（RFC 6749および6750）
2. コード交換（PKCE）の証明キー（RFC 7636）

oAuthインプリメンター（クライアントまたはその他）に最適な「パッケージ化された」ガイダンスは、IETF Best Current Practices（BCP）から入手できます。ほとんどの人はIETF RFCについて知っており、（紛らわしいことに）BCPはRFC番号付きのRFCとして公開されます。それにもかかわらず、これらはベストプラクティスであり、正式な仕様ではありません。

BCPプロセスは、提案された標準のプロセスと同様です。BCPは、レビューのためにIESGに提出され、IETFアナウンスメーリングリストの「最終呼び出し」を含む、既存のレビュープロセスが適用されます。ただし、IESGがドキュメントを承認すると、プロセスが終了し、ドキュメントが公開されます。結果のドキュメントはIETFの技術的な承認を得ていると見なされますが、そうではなく、公式のインターネット標準になることはできません。

確認するBCP：

1. oAuth セキュリティー（この記事の執筆時点で最新）
2. ブラウザベースのアプリの oAuth （この記事の執筆時点で最新）。
3. ネイティブアプリの oAuth （2017年に「コア」oAuth 2.0 RFCへのアップデートとして公開されていますが、まだよく読まれています）
4. oAuth用のJSON Webトークン（最新）

これらのドキュメントは、脅威モデルの用語で構成されています-攻撃（または希釈された形式としての「セキュリティの考慮事項」）と対策をカバーしています。あなたはもっと簡単なビルディングブロックタイプのロードマップを探しているかもしれませんし、おそらくそれは教育ツールとしてあるはずです。現実のoAuth実装は、脅威モデルの一応の証拠で開発する必要があります。

ある武士が言ったように：...戦いで試されていない剣術は、陸上で習得した水泳の芸術のようなものです。

また、独自の認証ソリューションを開発する理由をお聞かせください。

しかし、それはさておき、あなたが要求したことを正確に実行するオープンソースプロジェクト-Identity Serverがあります。あなたは彼らのソースコードをチェックアウトするか、それをフォークして、その上に何かを構築することができます。

また、さまざまなドキュメントで「同一」の回答を確認してください。