モバイルデバイスのログインフローに関するベストプラクティス

iOSやAndroidアプリケーションなど、ネイティブのモバイルアプリケーションを開発する場合には、ログインフローをネイティブまたはブラウザーベースから選択することができます。

• ブラウザーベースのログインフローでは、ユーザーにWebブラウザーが表示され、Auth0のログインページにリダイレクトされます。そこで、ユーザーはサインアップまたはログインすることができます。たとえば、iOSアプリケーションではSafariViewController、AndroidアプリケーションではCustom Chrome Tabが開きます。

• ネイティブのログインフローでは、ユーザーはサインアップを行うか、アプリに資格情報を直接入力します。

使用しているプラットフォームが対応している場合には、ブラウザーベースのログインログインフローをお勧めします。このプロ-では、ログインとサインアップのために、アプリケーションがアプリ内（埋め込み）ブラウザーを表示します。アプリ内ブラウザーを使用すると、認証状態やセキュリティのコンテキストを共有するなど、アプリケーションにブラウザーベースの認証のメリットがもたらされ、アプリケーションを切り替えてもユーザーエクスペリエンに影響はありません。選択するオプションにかかわらず、Auth0ではいずれかがサポートされます。

Google Drive、Google Docs/Sheets、YouTubeなど、複数のモバイルアプリがある場合、ユーザーがその1つにログインした際に、すべてのアプリにも自動的にログインさせると便利かもしれません。

アプリケーションが完全にネイティブのエクスペリエンスを使用している場合、ユーザーはアプリケーションごとに資格情報を入力しなければなりません。ところが、ブラウザーベースのログインフローを使うと、シングルサインオン（SSO）を実装して、ユーザーのログイン回数を減らすことができます。

Googleでは現在、Google SmartLockと呼ばれる、デバイス間でセッションを同期する機能の開発を進めています。これにより、ユーザーが1つのデバイスやデスクトップ/ノートパソコンからサインインすると、すべてのデバイス間でセッションを自動的に同期することができます。詳細については、Googleヘルプセンターの「複数のデバイスでパスワードを使用する」をお読みください。

SmartLockはまだすべてに対応できるものではありませんが、ブラウザーベースのログインフローを使うと、このツールを活用することができます。

ネイティブのログインフローでは、権限を持たない第三者がクライアントIDや認証URLを盗むために、逆コンパイルしたり、アプリケーションのトラフィックを傍受したりする可能性があります。権限を持たないユーザーがこの情報を使って不正なアプリケーションを作成し、アプリケーションストアにアップロードして、フィッシング攻撃によりユーザー名やパスワード、アクセストークンを盗み取る恐れがあります。

ブラウザーベースのフローを使用すると、Callback URLがユニバーサルリンク（iOS）やアプリリンク（Android）を介してアプリケーションにリンクされているため、この攻撃から保護されます。ただし、この機能は一般的にはサポートされていないことに注意してください。ユニバーサルアプリリンクの詳細については、apple.comでデベロッパ向けのユニバーサルリンクについてお読みください。アプリリンクの詳細については、「Androidアプリリンクの対応を有効にする」をお読みください。

ブラウザーベースのフローを使用すると、必要な実装時間を軽減できます。これは、多要素認証や攻撃防御といったあらゆる機能がホストされたログインページで処理されるためです。

ロックはデフォルトでユーザーエクスペリエンスを提供しますが、HTMLやCSSを使った独自のテンプレートでカスタマイズし、auth0.jsと統合することができます。

ユニバーサルログインエクスペリエンスを活用すれば、新機能を自動的に受け取ることができるため、ネイティブアプリケーションに変更を加える必要がありません。たとえば、Auth0がFIDO/U2F対応を追加すると、この機能性を使用するのに、アプリケーションのコードを変更する必要はありません。FIDO/U2Fの詳細については、yubico.comでFIDO U2Fについての概要をお読みください。

ネイティブのログインフローを使用すると、ログインUIとロジックがアプリケーションに含まれます。ブラウザーベースのログインフローでは、ページの読み込みにより長い時間がかかります。

ただし、モバイルデバイスでユーザーのログイン回数が低いことは注目に値します。ユーザーがログインしてしまえば、アクセスを取り消すか、ユーザーがログアウトすることを選んだ場合にのみ、アプリケーションはユーザーをログアウトさせます。

RFC 8252 OAuth 2.0 for Native Appsで説明されているように、ネイティブアプリからのOAuth 2.0認可要求は、外部のユーザーエージェント（主にユーザーのブラウザー）経由でのみ行われます。仕様にはその理由ついて、セキュリティと操作性の観点から詳しく記載されています。

ブラウザーベースのログインフローを実装する方法については、Quickstarts（クイックスタート）を参照してください。

• iOS（Swift）

• Android

ネイティブのログインフローについては、以下のGitHubリポジトリにサンプルがあります。

• iOS Swift

• Android