すでにこれに取り組んでいるかもしれません。アプリログインは正常に動作し、Google、Microsoft、またはメールアドレスでユーザーがサインインでき、APIはトークンを受け入れることができます。次に、主な質問が始まります。ユーザーは別のアカウントから請求書を表示できますか? デスクトップアプリはローカルにアクセストークンをキャッシュする必要がありますか? Capacitorビルドでconsentを取り扱う際に、ウェブビューとネイティブレイヤー間で状態をリークしないようにするにはどうすればいいですか?
チェックボックスから始まる認証は、製品の信頼性、インシデント対応、アプリストアのレビュー結果に影響を与えるようになります。特にCapacitorとElectronを使用するクロスプラットフォームアプリでは、認証の概念を理解することの難しさはそれほどありません。実際の問題は、ブラウザの仮定が適用されなくなった場所で実装すること、プラットフォームごとに安全なストレージの動作が異なること、クライアント側のショートカットがサーバー側のリスクを生み出すことです。
目次
- アプリケーション認証の本当の意味
- 認証の基本構成要素
- 認証の共通モデルとプロトコル
- OAuth 2.0 フロー アナトミー
- セキュリティの脅威と不可欠なベスト プラクティス
- 実装パターン: Capacitor と Electron
- セキュアなアプリ認証への道
アプリ認証とは何を意味するか
ユーザーがアプリをインストールし、 “Google での続行” をタップし、成功したサインインを実行し、そして、ID が認識された後、コンタクトやカレンダー データを読むことを許可するかどうかを尋ねるconsent画面に到達します。この瞬間には、ID の確認と、ID が認識された後、アプリが実行できることを定義するconsent画面が含まれます。
その区別はまだチームを混乱させる。 認証 ユーザーを証明する 承認 ユーザー、セッション、またはアプリがアクセスできるものを決定する。IDは建物に入るのに必要ですが、鍵はどのドアを開けるかを決定します。
アプリの作業では、その違いが重要です。チームはログインフローを保護し、次にそれ以降の設計を下回ります。トークンに過度に信頼し、サーバー側の許可チェックをスキップしたり、クライアントが許可ルールを制御するようにします。 したがって、「ユーザーがログインしている」は「ユーザーがアクセスできるものが多すぎる」に変わります。
承認は信頼が実際化される場所です。ユーザーは、アプリが自分が誰であることを知っていることを気にしません。彼らは、許可したものだけに触れるようにすることを気にします。
3 つのアクターを区別する必要があります:
- ユーザー ユーザーがログインし、同意を与える可能性があります。
- アプリケーション ユーザーの名前でアクセスを要求します。
- リソースの所有者またはAPI がデータを保護し、決定を強制する。
実際には、モバイルアプリの認可は、より強力なアクセス制御機能であるMFAと重複することもあります。2023年1月時点で、 世界中の約66％のユーザーがMFAを使用しており、, and JumpCloudのMFA統計のまとめ によると。認可を置き換えるものではありませんが、最初にアクセスを要求できるのは誰かを決める基準を上げることになります。 JumpCloudのMFA統計集計モバイルアプリのアクセス管理パターン
の概要は役に立ちます。 アプリケーションアクセス管理パターン Capgoはここで議論されている実装の選択肢の有用な相談相手です。
認証の基本構造
認証は、トークン内で魔法と扱うのではなく、より簡単になります。より良いメンタルモデルはホテルです。
ホテルのキーカードは良いメンタルモデルです
ゲストはフロントデスクに歩き、IDを提示します。ホテルはアイデンティティを検証し、滞在記録を作成し、キーカードを発行します。カードは、ドアを開けるたびにゲストのアイデンティティを証明するのではなく、特定の場所へのアクセスを許可する権限を保持します。
あなたのアプリは同じように動作します。
The important point is that the card isn’t the policy. It reflects policy. The doors still need a system that checks whether the card should open that specific lock. In software, that’s your API gateway, backend middleware, policy engine, or service-level authorization layer.
実際のシステムで重要な用語
主体
アクセスを要求する主体。通常ユーザーですが、デバイス、バックグラウンドジョブ、またはサービス アカウントでもあります。
リソース
保護されているもの。プロジェクト、請求書、管理ルート、ファイル、API エンドポイント、またはデータベース内のレコードの 1 つなどです。
スコープ
要求されているアクションのセット。プロフィールを読み取る。ファイルをアップロードする。請求を管理する。スコープは狭く理解しやすいものにする。
同意
ユーザーの承認。承認画面が明確で、要求されたアクセスのレベルを明確に示すものであれば、良好なものとなる。
アクセストークン
認証が成功した後、クライアントがリソースサーバーに提示する資格情報。機密情報として扱う必要がある。
実装上の多くのミスは、すべての要素を単一の仮定に圧縮することから生じる。 “ユーザーがトークンを持っているので、入るようにしてください。” という仮定は、実際には生産環境では機能しません。トークンは有効であるかもしれませんが、現在のアクション、テナント、環境、リソースに対しては不正である可能性があります。
モバイルとデスクトップのチームにとって、トークンハンドリングには特別な注意が必要です。ストレージは認証システムの一部であり、好きにしなくてもなりません。クライアントがアクセスアーティファクトを無責任に保存すると、ポリシー設計が後で救いません。このガイド モバイル開発者向けのセキュアなトークンストレージのガイド は、配信する前に確認する価値があります。
堅固なルールは単純です。認証、同意、トークン発行、サーバー側の強制は、頭の中とcodeで別々に保ちましょう。スコープを統合すると、通常、許可のバグを間違ったレイヤーでデバッグすることになります。
一般的な認可モデルとプロトコル
チームが「OAuthを使っている」と言っている場合、実際には同時に複数の意味を指していることが多い。混乱の原因の一つだ。
プロトコルは会話を取り扱う
OAuth 2.0 は主に委任認証について扱っている。アプリがユーザーの代わりに行動する許可を得る方法を定義し、ユーザーのパスワードを直接扱う必要がないようにしている。
OpenID Connect、またはOIDCはOAuth 2.0の上に乗っており、ユーザーの情報を追加している。実際にはOAuthは「このアプリが何ができるか」ということを答え、OIDCは「誰がログインしたか」ということを答える。
この違いはCapacitorアプリやElectronアプリで重要な問題となる。IDトークンをアクセストークンで使うことや、ログインが成功したのであればAPIがすべての後続のアクションを許可する必要があると誤解していることが多い。
あなたがこの機能をハイブリッドアプリに組み込む場合、ステップバイステップの OAuth2 の実装ガイド for Capacitor アプリ は__CAPGO_KEEP_0__アプリの開発者にとって避けられる流れのミスを防ぐための重要なリソースとなる。
モデルは決定論を取り扱う
あなたのシステム内では、許可が与えられるかどうかのルールが必要だ。それがモデルである RBAC と ABAC 入ります。
ロールベースのアクセス制御 (RBAC) 権限をロールにマップし、管理者、編集者、サポートエージェント、またはビューアなどの役割にします。一般的です。理解しやすく、監査可能で、比較的安定しています。BrightSecのセキュアな認証と認可の議論によると RBACは、細かい権限の強制に業界標準のメカニズムです。, BrightSecの議論で引用されている証拠によると、階層構造のロールと定期的な権限の監査を実装することで、RBACは企業環境でセキュリティインシデントを最大40%削減できます。Attribute-Based Access Control (ABAC) セキュリティ インシデントを最大 40% まで削減する企業環境.
属性ベースのアクセス制御 (ABAC) Attribute-Based Access Control (ABAC)
実践ルール: 製品の権限が安定し、人間が読みやすい場合にRBACから始めましょう。 ABACを追加するのは、実際に決定を変えるコンテキストがある場合のみです。
RBACとABACの比較
| 基準 | ロールベースのアクセス制御(RBAC) | 属性ベースのアクセス制御(ABAC) |
|---|---|---|
| 基本概念 | ロールに基づいてアクセスが許可される | 属性を評価してアクセスが許可される |
| 最適なフィット | 内部ツール、ダッシュボード、管理パネル | マルチテナントアプリ、規制されたワークフロー、コンテキスト依存のアクセス |
| [ | 推論の容易さ | チームや監査員にとって理解しやすい |
| より柔軟ですが、デバッグが困難 | 変更管理 | 役割の追加または変更 |
| ポリシーの調整と属性ルール | 共通の失敗モード | 役割のスプラウル |
| Example | 例 | 「サポートエージェントはチケットを表示できます」 |
最先進のモデルを選択するための賞品はありません。チームが一貫して実行できる選択肢がベストです。多くの製品コードベースでは、広範なアクセス境界と例外として所有権、テナント、またはデバイス状態などのターゲット属性を使用したRBACが必要です。
OAuth 2.0 フローの解剖学
A lot of OAuth explanations stay abstract for too long. In a real app, the sequence matters, especially for public clients like Capacitor and Electron apps that can’t safely keep a client secret.
ユーザーがログインをタップしたときのこと
ユーザーが Capacitor アプリを開き、「GitHub でログイン」をタップすると、アプリは PKCE code 生成器と派生 code チャレンジを作成し、システムブラウザまたは安全ブラウザタブでユーザーを認可サーバーに送ります。アプリは、リクエストを開始したものであることを確認するために、状態も含めます。
認可サーバーでは、ユーザーが必要に応じてサインインし、要求されたアクセスを承認します。サーバーは、直接使用できる長期的な資格情報を含まない認可 code をリダイレクトします。アプリは、構成済みのリダイレクト URI を通じてその code を受け取ります。
アプリはcodeをトークンに交換します。PKCEはこのプロセスで重要です。アプリは元のcodeの検証者と認証codeを送信します。サーバーはそれを元のcodeのチャレンジと比較します。もし一致すればトークン交換に成功します。もし誰かがcodeをインターセプトしたが検証者を持っていない場合、交換は失敗します。
そのためPKCEはネイティブおよびハイブリッドクライアント向けに不可欠です。これらのアプリはパブリッククライアントです。攻撃者がバンドルを検査したり、codeパスを逆アセンブルしたり、ローカル状態を改ざんしたりできることを想定してください。PKCEはリダイレクトベースフローの最も一般的なリスクの1つを狙っています。
実装のシーケンスをcodeに実装する前に視覚的なリフレッシュを得たい場合は、以下の簡単なウォークスルーを参照してください。
クロスプラットフォームアプリは通常ここで破綻します。
プロトコルは簡単です。実装はしばしばそうではありません。
Capacitorアプリは通常、以下のいずれかの場所で失敗します。
- ウェブビュー内でのサインイン リダイレクト状態を失うことです。
- アプリがブラウザからネイティブシェルに復帰したときに。 トークンを平文のブラウザストレージに保存することです。
- プロジェクトはWebアプリとして始まり、チームはモバイル用にストレージを再検討しなかったためです。 ここで、クロスプラットフォームアプリは通常ここで破綻します。
Electronアプリには別の問題が存在します。チームはレンダラープロセスが認証ロジックを多すぎる場合、IPCを使用してトークンを厳格な境界なしで公開する場合、またはデスクトップアプリを信頼できる環境として扱う場合があります。そうではありません。パッケージされたデスクトップアプリは、敵対的なクライアントの視点を持つ必要があります。
リフレッシュ動作も意図的に設計する価値があります。アクセストークンは期限切れになり、セッションはきれいに復元され、複数の同時要求に対してリフレッシュロジックが競合条件を生成しないようにする必要があります。 セキュアなトークンリフレッシュフロー ガイド これは、リトライループや古いセッションの混乱に陥わないように、構築するための堅固な基準です。
1 つの実装慣行が最も役立つことは、明確な入力と出力を持つ小さな認証モジュールで OAuth ハンドシェイクを分離することです。リダイレクトハンドリング、トークンパース、リフレッシュロジックをコンポーネント、フック、ランダムなネットワークユーティリティに散らすのではなく。
セキュリティの脅威と基本的なベストプラクティス
認証のバグは code のレビューでは劇的なもののように見えません。代わりに、便利さのように見えます。幅広いスコープ、キャッシュされたトークン、UI がボタンを隠しているためサーバー側のチェックを省略するなど。アプリがリリースされると、その短縮が攻撃面になります。
繰り返し出現する失敗
モバイルエコシステムは有用な警告サインを提供します。DeepStrike のモバイルセキュリティ統計によると、 DeepStrikeのモバイルセキュリティ統計, ,, and 分析したモバイルアプリの85％にセキュリティの欠陥が存在したセキュリティのマーケティングのフレーミングを受け入れる必要はありませんが、セキュリティの重要な信号を受け入れることは大切です。
パターンはよく知られています:
- 漏洩したトークン 不正なストレージ、ログ、クラッシュレポート、またはレンダラーにアクセス可能な状態から漏洩したトークン。
- 過度に広範なスコープ すべてを要求するのは、時間の経過とともにconsentを進化させることよりも簡単なので、過度に広範なスコープが生じます。
- クライアントサイドの強制 アプリは非承認されたアクションを隠しますが、APIはそれらを受け入れることになります。
- 再生とリダイレクト攻撃 状態、PKCE、またはリダイレクトURIの検証が粗雑な場合に発生する再生とリダイレクト攻撃。
- 許可のずれ チームがロールと例外を追加し、定期的なレビューなしで
保護されたアクションに対して、バックエンドが認証を検証しない場合、認証アプリはありません。UIヒントだけがあります。
実用的なチェックリスト
最小権限の原則をデフォルトとして使用しましょう。実際のプロジェクトでは、各トークンが実行できるものを縮小し、各トークンが存在する場所を縮小し、各クレデンシャルが有効な期間を縮小します。
- スコープを狭く要求する: 現在使用している機能に対して必要な権限だけを要求します。アプリがconsentを遅らせることができる場合は、そちらを優先してください。
- サーバー上で強制する: クライアントを信頼できないものと扱いましょう。ボタン、ルート、非表示の画面はセキュリティの境界ではありません。
- プラットフォームの安全なストレージを使用する: モバイルでは、ネイティブのキーチェーンまたはキーストアへのアクセスをプラグインを通じて使用するのではなく、平文のローカルストレージを使用してください。デスクトップでは、敏感なデータを容易にアクセスできるレンダラーから外に保管してください。
- 状態とリダイレクトハンドリングを検証する: アプリの認証応答は、実行したアプリのリクエストと一致する必要があります。
- 期限切れを早期に設定し、リフレッシュを慎重に実行します: 短期間のアクセストークンは、漏洩した場合の被害を制限します。リフレッシュロジックは、クリーンに回転し、クローズドで失敗するように実装する必要があります。
- 必要に応じて、トークンを無効化して再認証を強制することができます: セッション終了とインシデント対応には、トークンを無効化し、再認証を強制する機能が含まれます。
- 入力値を検証し、トランスポートを保護します: HTTPS、適切な証明書ピンニング、および入力値検証はすべて重要です。認証が周辺の弱点を通じてバイパスされる可能性があるためです。
ストアを通じてアプリを配信するチームにとって、認証設計はまた、API の漏洩と合規性レビューとともに交差します。この API のアプリストアの合規性セキュリティ基準の概要は、認証チェックリストとともに適切です。 API アプリストアの規制に適合するためのセキュリティ基準 __CAPGO_KEEP_0__ と Electron の実装パターン
__CAPGO_KEEP_0__
Capacitor
プラットフォームを横断するアプリケーション認証は、ブラウザにパッケージを追加しただけのアプリと見なすのをやめれば簡単になります。CapacitorとElectronは、ネイティブストレージ、プロセス境界、リダイレクトハンドリングを尊重するパターンが必要です。
Capacitorのパターンが機能する
Capacitorの場合、システムブラウザOAuthをサポートするプラグインまたは認証ライブラリを使用し、PKCEと適切なデープリンクまたはアプリリンクコールバックを使用してください。ライブラリの例は capacitor-oauth2 codeを削除できますが、トークンストレージとリフレッシュ動作を明示的に維持する必要があります。
実用的構造は次のようになります。
- 認証コーディネーター: ログインを開始し、状態を追跡し、コールバックを処理します。
- トークンサービス: ネイティブセキュアストレージを使用してトークンを保存し、ブラウザストレージを使用しないようにします。
- APIクライアント: アクセストークンを付属し、リフレッシュに一度リトライし、回復不能な失敗の場合には強制的にサインアウトします。
- ポリシー認識バックエンド: トークン要求をサーバーサイドの認証チェックにマップします。
セッションツールがハイブリッドアプリライフサイクルに適合するようにしたい場合は、オプションを評価している場合、 Capacitor セキュアなセッション管理用のプラグインの比較 は、適切なアプローチを検討するための良い場所です。
トークン更新の最小限の形状は次のようになります。
async function authorizedFetch(request) {
let token = await tokenStore.getAccessToken()
let response = await api(request, token)
if (response.status !== 401) return response
const refreshed = await auth.refresh()
if (!refreshed) {
await auth.signOut()
throw new Error('Session expired')
}
token = await tokenStore.getAccessToken()
return api(request, token)
}重要なのは、リフレッシュを中央化することです。すべての画面がセッションの動作を独自に作成するのではなく。
Electron パターンが必要な注意事項
Electron には厳格な境界が必要です。トークン交換と安全なストレージを主プロセスに保管し、可能な限りレンダラーに狭いIPCメソッドを公開するのではなく、レンダラーにrawトークンを渡して期待するのではなく。
デスクトップアプリはモバイルアプリよりもコントロールが可能なように感じる。そうした感覚をリスクではなく、保証とみなす。
避けるべき短絡
- レンダラーアクセス可能なローカルストレージにトークンを保存しない 避けることができるなら。
- すべてのウィンドウが広範な認証コンテキストを共有するのを避けましょう。 ウィンドウの目的とセッションの有効期限を確認せずに実行しないでください。
- プリロードスクリプトに依存して過度に信頼しないでください。 プロセス隔離と明示的なAPI境界の代わりに。
Operational visibility is also important. 実際には、拒否されたアクション、トークン更新の失敗、ロールの変更、consentの取り消し、不審なリソースアクセスパターンをログに記録する必要があります。ハイブリッドアプリの更新が含まれるリリースプロセスがある場合、このエコシステムでは、以下のオプションが考えられます。 __CAPGO_KEEP_0__Capgoにプルリクエストを送信する際は、
Capgoのプルリクエストを送信する際は、 Capgo、が提供される、署名のライブアップデートはCapacitorとElectronアプリケーションに提供されます。それは認証を実装しませんが、authロジック、リダイレクトハンドリング、またはセッションcodeが急いで修正する必要がある場合に、修正を迅速に実装することができます。
セキュアなアプリ認証へのあなたの道
良いアプリ認証は単一の決定ではありません。すべての決定が互いに組み合わさって機能する必要があります。ユーザーを正しく認証し、必要なアクセスのみを要求し、OAuth 2.0とPKCEを使用した安全なフローでトークンを交換し、正しい場所にシークレットを保存し、サーバー毎回の許可を強制する必要があります。
CapacitorとElectronチームにとって最も重要なのは、端の Disciplineです。ブラウザ時代のショートカットは、ネイティブストレージ、深いリンク、デスクトッププロセス境界、またはアプリレビュー要件と接触すると存続できません。トラブルを避けるチームは、通常、なんらかの特別なことはしていません。スコープ、セッションハンドリング、サーバーサイドチェック、監査可能性について、均一性を持っています。
現在の認証設定が絡み合っている場合、それは正常です。最初に、1つの境界を一つずつ強化してください。フローを修正してください。ストレージを修正してください。アクセスルールをUIから外してください。許可されていないものを要求したときに誰がログインしたかを知るためのログを追加してください。
それが、セキュアなアプリ認証が管理可能になる方法です。理論上は単純ではありません。codeで安全です。
Capgoは、CapacitorやElectronアプリの修正を、ストアのレビューの待ちなしで配布することができます。これは、認証フロー、トークンハンドリング、セッションのバグを早期に修正する必要がある場合に重要です。チームがクロスプラットフォームのリリース、ターゲットされたロールアウト、ロールバックサポートをより制御できる場合、 Capgo は、認証スタックとともに評価する価値があります。
