顧客のオンボーディング体験を向上させるためのちょっとしたコツ

Logto では、顧客のためのオンボーディングプロセスを改良することに非常に重点を置いています。ユーザーのサインアップやサインイン体験をできるだけ簡単でスムーズにすることの重要性を理解しています。この記事では、ユーザーのサインアップ体験を向上させるために使うべき2つの小さなコツを共有します。

最初の画面#

OIDC 認証プロセスを簡単に見てみましょう。

クライアントアプリケーションからユーザーが認証リクエストを送信すると、Logto で OIDC 認証セッションが開始されます。その後、ユーザーは Logto がホストするログインページにリダイレクトされ、資格情報を入力して身元を確認します。ユーザーが正常にログインすると、認証レスポンスがクライアントアプリケーションに返送されます。

デフォルトでは、ユーザーにはサインイン画面が表示されます。

ユーザーがアカウントを持っていない場合、「登録」ボタンをクリックしてサインアップ画面に切り替えることができます。

しかし、ユーザーが最初からサインアップするつもりでアプリケーションにアクセスしている場合、サインイン画面をスキップして、デザインされたサインアップ画面に直接移行したいと思うでしょう。

これは、認証リクエストに first_screen パラメータを追加することで簡単に実現できます。

または、サポートされている SDK での実装:

first_screen パラメータには signIn または register の2つの値を設定できます。

first_screen パラメータを register に設定することで、サインイン画面をスキップして、ユーザーをサインアップ画面に直接移行させることができます。

ちょうど Logto のホームページのように。

ユーザーが Get started ボタンをクリックすると、サインアップ画面に直接移動します。

直接サインイン#

もう 1 つ知っておくと便利な認証パラメータは direct_sign_in です。このパラメータを使用すると、サインイン画面をバイパスして、直接ソーシャルまたはエンタープライズ SSO 認証フローを開始できます。

これは、独自のソーシャルおよびエンタープライズ SSO エントリーポイントを持ち、Logto のサインイン画面をスキップしたい場合に特に便利です。

たとえば、direct_sign_in パラメータが指定されていない場合のエンタープライズ SSO ユーザージャーニーは次のようになります。

1. デフォルトのサインイン画面が表示されます。
2. メールアドレスを入力します。

3. シングルサインオンが検出され、その後ユーザーは Single Sign-On ボタンをクリックして SSO フローを開始します。

4. さらに、同じメールドメインの下で複数の SSO プロバイダーが設定されている場合、ユーザーは希望する SSO プロバイダーを選択するよう求められます。

このフローは、ユーザーが希望する SSO プロバイダーを事前に知っている場合に簡略化できます。

direct_sign_in パラメータは次の値を取ることができます:

• social:<provider-name>: サードパーティのソーシャル認証フローを直接開始します。 (例: social:google)
• sso:<connector-id>: エンタープライズ SSO 認証フローを直接開始します。 (例: sso:1234567890)

direct_sign_in パラメータを認証リクエストに追加します:

または、サポートされている SDK での実装:

direct_sign_in パラメータを使用すると、ユーザーは指定されたアイデンティティプロバイダーの認証ページに直接リダイレクトされます。認証プロセスを完了するために必要な手順が大幅に削減されます。

結論#

Logto では、ユーザー体験を非常に重視しています。first_screen および direct_sign_in パラメータを使用することで、顧客のオンボーディングプロセスを大幅に強化できます。

カスタマイズされた視覚的に魅力的なサインアップ画面を作成したい場合は、custom-css 機能をぜひご利用ください。

詳細については、authentication parameters をご参照ください。