たとえば、.NET APIに接続してデータを受信/設定するAndroidアプリケーションがあるとします。ユーザーが最初にサインアップ/ログインし、APIへのリクエストを行うたびに認証する方法について、私が混乱しています。
他にどのパターンが利用可能で、最も効率的で安全なのか、そのためのプロセスフローが必要です。モバイルアプリケーションからサーバーへのすべてのリクエストを認証するために、Facebook、FourSquare、Twitterなどの有名なAndroidアプリケーションがどの方法を使用するかを誰かに教えてもらえますか？
それがいくつかの公開情報でない場合は、事前に申し訳ありません。
回答:
彼らは「トークン」ベースのセキュリティシステムを使用していると思います。そのため、パスワードは実際にはどこにも保存されず、初めて認証に使用されるだけです。したがって、アプリは最初にユーザー名/パスワードを（ssl経由で）投稿し、サーバーはアプリが保存するトークンを返します。後続の同期試行では、トークンが最初に送信され、サーバーはそれが有効であることを確認してから、他のデータを送信できるようにします。
サーバーが認証試行を再要求できるように、トークンには有効期限が必要です。
Androidフレームワーク内から同期アダプターに接続すると、内部ですべてを同期および認証できるようになります。
http://developer.android.com/training/sync-adapters/creating-sync-adapter.html
デバイスの[設定]でアカウントを確認すると、意味がわかります。
基本的にこれらの有名な使用OAuthプロトコル（1）/フレームワーク（2）。これは標準である必要がありますが、これらはそれぞれ、このプロトコル/フレームワークの実装が異なります。そのため、統合に関しては非常に注意する必要があります。
例：Dropboxは引き続きOAuth 1を使用しており、最近OAuth 2のサポートが登場しました。
回答に戻ると、peterpanが述べたように、これはトークンベースの認証方法であり、1回限りのものであり、方程式とは異なります。
この背後にある興味深いことは、クライアントアプリケーションが危険なユーザー名とパスワードを保持するのではなく、リソースアクセススコープを定義できることです。
これは、これがどのように機能するかの基本的なイラストです。
私は最近この分野で働いているので、これの詳細を取得した後、答えを更新します:)
ユーザー名/パスワードベースの認証だけを使用する場合、それらは十分に安全ではありませんか？
いいえ、あなたはWHOがAPIサーバーにアクセスしているだけで、WHATがAPIサーバーにアクセスしているのではないことを識別しているためです。
WHOとWHATがAPIサーバーにアクセスしている違いをよりよく理解するために、次の図を使用してみましょう。
Intended Communication Channelは、悪意のある意図を持たない正当なユーザーが、改ざんされていないバージョンのモバイルアプリを使用し、中間者に攻撃されることなくAPIサーバーと直接通信することで、期待どおりにモバイルアプリを使用していることを表します。
実際のチャネルは、悪意のある正当なユーザーがモバイルアプリの再パッケージバージョンを使用している可能性のある合法的なユーザー、モバイルアプリの正規バージョンを使用しているハッカー、途中で人間が攻撃している方法など、いくつかの異なるシナリオを表している可能性があります。 APIに対する攻撃を自動化できるようにするために、モバイルアプリとAPIサーバー間の通信が行われています。他にも多くのシナリオが考えられますが、ここではそれぞれを列挙しません。
WHOとWHATが同じではない理由がすでにわかっていると思いますが、そうでない場合はすぐに明らかになります。
WHO我々は、認証、認可およびOpenIDを接続またはのOAuth2フローを使用してのように、いくつかの方法で識別できることを、モバイルアプリの利用者です。
一般に、OAuthは、リソース所有者に代わってサーバーリソースへの「安全な委任アクセス」をクライアントに提供します。リソース所有者が資格情報を共有せずにサーバーリソースへのサードパーティアクセスを承認するプロセスを指定します。ハイパーテキスト転送プロトコル（HTTP）と連携するように特別に設計されたOAuthは、基本的に、リソース所有者の承認を得て、認証サーバーからサードパーティのクライアントにアクセストークンを発行できるようにします。次に、サードパーティはアクセストークンを使用して、リソースサーバーによってホストされている保護されたリソースにアクセスします。
OpenID Connect 1.0は、OAuth 2.0プロトコルの上にあるシンプルなIDレイヤーです。これにより、クライアントは、承認サーバーによって実行された認証に基づいてエンドユーザーの身元を確認し、相互運用可能なRESTのような方法でエンドユーザーに関する基本的なプロファイル情報を取得できます。
ユーザー認証により、APIサーバーがWHOがAPIを使用していることを認識できる場合がありますが、要求が元のバージョンのモバイルアプリである予期したものから発生したことを保証することはできません。
今、私たちは特定する方法必要WHAT APIサーバーを呼び出して、ここで物事はほとんどの開発者が考えることよりも、よりトリッキーになっているが。WHAT APIサーバに要求を行うものです。それは本当にモバイルアプリの本物のインスタンスですか、それともボット、自動化スクリプト、またはPostmanなどのツールを使用して手動でAPIサーバーを操作する攻撃者ですか？
驚いたことに、モバイルアプリの再パッケージ化されたバージョンを使用している合法的なユーザー、またはアプリケーションが提供するサービスを悪用して利用しようとしている自動化されたスクリプトであることに気付くかもしれません。
まあ、識別するために、何を、開発者は、APIキーを自分の携帯アプリのコードで、通常、彼らはハードコードそれに頼る傾向があります。一部の開発者は、余計な作業を行って、モバイルアプリで実行時にキーを計算するため、静的なシークレットがコードに埋め込まれている場合の以前のアプローチとは異なり、ランタイムシークレットになります。
上記の記事は、私が書いた記事「モバイルアプリにAPIキーが必要なのはなぜですか？」、そしてここで詳しく読むことができます。これは、APIキーに関する一連の記事の最初の記事です。
もちろん、セキュリティ上の理由から、そのユーザー名/パスワードをデバイスに保存することはできませんか？サインアップ時にすべてのユーザーに対してGUIDを発行し、それをデバイスに保存して、APIリクエスト中に毎回取得する必要がありますか？
デバイスに保存したものは、暗号化されていても、FridaやXposedなどのツールを使用してランタイム中にリバースエンジニアリングできます。
独自のスクリプトをブラックボックスプロセスに挿入します。関数のフック、暗号APIのスパイ、プライベートアプリケーションコードのトレース。ソースコードは不要です。編集して保存をクリックすると、すぐに結果が表示されます。コンパイル手順やプログラムの再起動なしですべて。
Xposedは、APKに触れることなく、システムとアプリの動作を変更できるモジュールのフレームワークです。これは素晴らしいことです。なぜなら、元のコードが変更されていなければ、モジュールは変更なしでさまざまなバージョンやROMでも機能するからです。
デバイスでは、攻撃者のコントロールは、彼はまた、あなたが識別するために使用することができます任意の秘密を抽出するために、中間者攻撃を実行するためにプロキシを使用することができますWHATやWHO私は記事に表示としては、攻撃で男とそのAPIキーを盗みます：
JNI / NDKなどの高度な手法を使用してモバイルアプリのコードでAPIキーを非表示にすることはできますが、APIキーを盗むためにMitM攻撃が実行されるのを妨げることはありません。実際、MitM攻撃は、開発者以外でも達成できるほど簡単です。
では、何が...私のAPIサーバーが悪用されるのを防ぐことができないほどの運命にありますか??? 静かではありません...希望がまだ存在しています!!!
モバイルアプリケーションからサーバーへのすべてのリクエストを認証するために、Facebook、FourSquare、Twitterなどの有名なAndroidアプリケーションがどの方法を使用するかを誰かに教えてもらえますか？
申し訳ありませんが、このアプリに関する十分な知識がないため、説明を行うことができませんが、他のいくつかのアプローチを紹介します。
他にどのパターンが利用可能で、最も効率的で安全なのか、そのためのプロセスフローが必要です。
したがって、クライアント側で実行され、APIにアクセスするためにシークレットが必要なものは、さまざまな方法で悪用される可能性があり、モバイルAPIのセキュリティテクニックに関するこのシリーズの記事で詳細を学ぶことができます。この記事では、APIキー、ユーザーアクセストークン、HMAC、TLSピニングを使用してAPIを保護する方法と、APIをバイパスする方法について説明します。
WHATがモバイルアプリにアクセスする問題を解決するには、前述のモバイルAPIのセキュリティテクニックに関する一連の記事に記載されているソリューションの1つまたはすべてを使用する必要があります。これらのソリューションでは、APIサーバーへの不正アクセスのみが困難になることを認めています。バイパスは不可能ではありません。
APIサーバーが本物のモバイルアプリからのリクエストのみを受信していることを知ることができるモバイルアプリ認証ソリューションを使用することで、より優れたソリューションを採用できます。
モバイルアプリアテステーションソリューションを使用することは知っているAPIサーバが有効になりますWHAT危険なソースからの他のすべての要求を拒否しながら、唯一の本物のモバイルアプリからの要求に応答することができますので、リクエストを送信しています。
モバイルアプリ認証ソリューションの役割は、モバイルアプリが改ざんされていないこと、ルート化されたデバイスで実行されていないこと、xPosedやFridaなどのフレームワークによって計測されていないこと、MitM攻撃されていないことを実行時に保証することです。 SDKをバックグラウンドで実行することで実現します。クラウドで実行されているサービスはアプリにチャレンジし、その応答に基づいて、モバイルアプリとデバイスが実行されている完全性を証明します。したがって、SDKが決定に責任を負うことはありません。
モバイルアプリの整合性の認証に成功すると、短期間のJWTトークンが発行され、APIサーバーとクラウド内のモバイルアプリ認証サービスのみが認識している秘密で署名されます。モバイルアプリの認証に失敗した場合、JWTトークンは、APIサーバーが知らない秘密で署名されます。
これで、アプリはリクエストのヘッダーにあるすべてのAPI呼び出しでJWTトークンを送信する必要があります。これにより、APIサーバーは、JWTトークン内の署名と有効期限を検証できる場合にのみリクエストを処理し、検証に失敗した場合にリクエストを拒否できます。
モバイルアプリ認証サービスで使用されるシークレットがモバイルアプリで認識されない場合、アプリが改ざんされているか、ルート化されたデバイスで実行されているか、または中間者攻撃のターゲット。
Mobile App Attestationサービスは、iOS、Android、React Nativeなどを含むいくつかのプラットフォーム用のSDKを提供するSAASソリューションとしてApproov（私はここで働いています）にすでに存在しています。統合では、クラウドサービスによって発行されたJWTトークンを検証するために、APIサーバーコードの小さなチェックも必要になります。このチェックは、APIサーバーがどの要求を処理し、どの要求を拒否するかを決定できるようにするために必要です。
結局のところ、APIサーバーを保護するために使用するソリューションは、ヨーロッパのGDPR規制のように、保護しようとしているものの価値とそのタイプのデータの法的要件に従って選択する必要があります。
OWASPモバイルセキュリティプロジェクト-上位10のリスク
OWASPモバイルセキュリティプロジェクトは、セキュリティで保護されたモバイルアプリケーションを構築および維持するために必要なリソースを開発者やセキュリティチームに提供することを目的とした、一元化されたリソースです。プロジェクトを通じて、私たちの目標は、モバイルセキュリティリスクを分類し、その影響または悪用の可能性を低減するための開発管理を提供することです。
私はまったく同じものを検索していて、ピーターパンのような何かがグーグルAPIを介してグーグルの方法を見つけました。このリンクとGoogleを試してみてください。私も始めています！新しい情報を投稿します。
ユーザー名とパスワードは、SharedPreferencesに配置すると安全です。 サーバーへの接続にhttpsを使用することも同様に十分です。