私の会社は、中程度の機密情報 (つまり、口座番号ではなく財務情報) を返す RESTful API を構築しています。私は RESTful API コード/サーバーを制御しており、Android アプリも構築しています。私は認証コード許可フロー (クライアント ID とシークレット) で OAuth 2 を使用するように API をセットアップしました。クライアントとプロバイダーの両方を所有しているため、クライアントを承認する必要なくユーザーを自動承認します。私たちは SSO に CAS を使用しており、ユーザーがログインしてトークンを取得するときの OAuth 2 プロセスの一部として、認証サーバーにこれを使用しています。
Android アプリのデータを保護するためのさまざまな方法を検討しています。クライアントIDとシークレットをデバイスに保存することは絶対にないと結論付けましたが、認証トークンを保存することはうまくいくかもしれないと考えています.根ざした電話）。
ここに私が考えた2つのオプションがあります。どちらも、CAS で保護された一種のプロキシ サーバーが必要であり、API サーバーでダンスを行い、認証トークンを返します。これにより、クライアント ID とシークレットをアプリ コードに格納する必要がなくなります。
ここに私が思いついたものがあります：
1) ユーザーがアプリを起動するたびに、データにアクセスするにはパスワードを入力する必要があります。これは間違いなく最も確実な方法です。これが行われた場合、おそらく便宜上ユーザー ID を保存したいと思いますが、その場合、CAS ログインを使用できませんでした (Web ベースであるため)。バックエンドでヘッドレス ブラウザを使用して、ユーザーを CAS にログインさせ、Android フォームに入力した内容に基づいてトークンを取得できるかもしれませんが、これはハックのようです。ユーザー ID の保存は、Chase アプリが行うことと似ています (たまたまこれを使用している場合)。ユーザー ID は保存されますが、セッション間のパスワードは保存されません。
2) 認証トークンを Android デバイスに保存します。これは安全性が少し劣りますが、ほぼ確実です。ユーザーがアプリを初めて起動するときに、トークンを返すプロキシ サーバーの CAS ログインの Web ページを開きます ( https://developers.google.com/accounts/docs/MobileAppsと同様)。ユーザーがログインし、トークンがアプリに返されたら、トークンを暗号化し、アプリケーションに対してプライベートに保存します。また、ProGuard を使用してコードを難読化し、暗号化アルゴリズムのリバース エンジニアリングをより困難にします。トークンの更新でも作業できますが、これはより誤った安心感になると思います。
3) CAS を使用せずに、サービスの認証トークンを取得する別の方法を考え出します。
他の人が同様のシナリオをどのように実装したかについてのアドバイスはありますか (それが行われた場合)?
ありがとう。