私はアプリケーションを作成しています。広告を投稿するクライアントと、表示して追加を受け入れるユーザーの両方がいます。クライアントはメインWebサーバーサイトにログインして追加をポストし、ユーザーはログインして（承認を得て）モバイルサイトを表示します。oauth2 issue with user api
ここで、私はoauth2認証を使用しています...私はサーバを設定し、認証コードを取得するためにカールを使用しましたが、誰かが私に何かを明確にしてもらえますか？
クライアントとユーザーは同じデータベーステーブルに格納されていますか？ apiを表示したいと思う各人をUsersに保存するか、Users/Whateverのための新しいモデルを作成しますか？
このシナリオでは、多くのチュートリアルではサードパーティのアプリケーションがGoogleなどのように認可を受けているため、このシナリオではさらにoauth2が必要ですか。私のモバイルアプリケーションとWebサーバーは、どちらも同じ会社またはサイトの一部です。
私はあなたの質問を正しく理解することを願っています。最初の質問はデータベース設計に関するもので、2番目の質問では、oauthの使用例の理解を探しています。
あなたの最初の質問についてお話ししましょう。答えは少し具体的ではありません。これは設計上の決定であり、やや主観的ですが、お客様の要件に基づいて、より良いまたは悪い解決策を示します。ユーザーとクライアントについて保存する必要のある情報が大幅に異なるかどうかを判断する必要があります。そうであれば、異なるテーブルがあなたのより良い設計ソリューションになります。クライアントとユーザーについて知る必要があるのは、アクセスの種類が異なる場合だけです。必要なのは、ログインしたユーザーのアクセスの種類を示す列がテーブルに追加されていることですクライアントまたはユーザーです。この場合、単一のテーブルがより良い設計ソリューションになります。
oauthの目的がよく理解されていないため、いったん使用すると、実装するのが簡単ではないので、2番目の質問は多くの開発者にとって大きな疑問ともなりません。 Oauthは、クライアントとサーバーの間の安全なハンドシェイクと考えることができます。この場合、クライアントはあなたですが、サーバもあなたです。つまり、あなたはoauthを必要としません。他の開発者のクライアントアプリケーションにデータを提供できるバックエンドを作成する場合は、oauthを実装することもできますが、サーバーからの認証セキュリティが必要な場合にのみ使用することもできます。最初はちょっと混乱していましたが、続けることができましたが、oauthを使用してアプリを実装した人が書いた非常によく説明するarticleがあります。まだoauthが必要だと思う場合（コードを他の開発者がAPIとして使用することを計画している場合）、あなたはあなたの仕事を減らします。それ以外の場合は、今はoauthを心配しないでください！
ああ、ありがとうございます。私は遠くに行く気分だった。だから、基本的なdjango認可は、ユーザーとクライアントが私のモバイルアプリケーションから私のWebサーバーAPIにアクセスするのに十分なセキュリティですか？データベースについては、djangoアプリケーションを作成したときに作成された追加の列をユーザーのテーブルに追加するにはどうすればよいですか？または、「管理者」ユーザー用のユーザーセクションであり、ユーザー/クライアント用に独自のテーブルを作成する必要がありますか？ – Denis
既存のユーザーモデルを拡張することができます。私はドキュメントの最初の方法をお勧めします。[ここ]（https://docs.djangoproject.com/ja/1.10/topics/auth/customizing/#extending-the-existing-user-model）に示されています。理解して実装するのが最も簡単です。 [this]（http://stackoverflow.com/questions/44109/extending-the-user-model-with-custom-fields-in-django）を参照してください。 –