0

モバイル バックエンド サービスを構築しています。私は、Authentication Service のようなサービスが App key と App secret を一連のサービス (論理的には app と呼ばれる) を購入する人々に提供することを想像してみてください。

X 、 Y 、 Z などのサービスと AuthService があるとします。

アプリに「ユーザー」という概念がないと仮定すると、アプリ キーとアプリ シークレットを使用して、サービスの API アクセスを制限できると考えました。

しかし、

(appkey , appsecret)と同じくらい良いため、ローカルで検証できないため(username , password)、API 呼び出しが有効かどうかを確認するために AuthService サービス呼び出しを行う必要があります。ただし、サービス X へのすべての呼び出しは実際には2 つのサービス呼び出しであるため、これはパフォーマンスに影響します。

私の質問: 通常、アプリはまったく検証されていますか? なぜ appkey と appsecret を使うのでしょうか? 自己完結型のアプリから「アプリトークン」を取得しないのはなぜですか。AuthService呼び出しを行う必要はありません。常に Https を使用して中間者を回避し、アプリ トークンを SDK によって安全に保存することができます。

X 、 Y 、 Z などのサービスでアプリ情報 (app-token) をキャッシュし、ローカルで検証するなどのソリューションについて聞いたことがあります。ただし、アプリのキーとシークレットを取得すると、保存場所に関係なくパーティーを行うことができます。また、個々のサービスではキャッシュが冗長になります。認証情報もキャッシュに保存することになり、キャッシュはすぐに変更される可能性があります。キャッシュの無効化が問題になる可能性があります。?

助けてください、よろしくお願いします。

4

2 に答える 2

0

説明されているシナリオは、自己完結型のベアラー アクセス トークンを使用したOAuth 2.0承認の典型的なケースのように見えます。

クライアントは認証され、OAuth 2.0 認証および/またはトークン エンドポイントでアクセス トークンが発行されます。アクセス トークンは、OAuth 2.0 サーバーの RSA キーで署名された JSON オブジェクトでアクセス許可の範囲と有効期間をエンコードする署名付きJWTで表すことができます。X、Y、および Z サービスは、要求をクリアするために JWT アクセス トークンを受信したときに署名を確認するだけで済みます。これにより、認証サービスへのネットワーク呼び出しが節約され、RSA 署名チェックは約 100 マイクロ秒で実行できます。これは、HTTP 要求よりもはるかに短い時間です (数十ミリ秒以上)。

于 2014-04-01T07:37:53.600 に答える