ノーコードツール【Bubble】ユーザー認証の仕組みと仕様を解説

組み込みのUser Typeを使用すると、アプリでユーザー認証を処理することができます。ユーザーは、メールアドレス、または外部サービス（Facebook OAuthなど）を通して認証される場合はIDによって一意に定義されます。

ユーザーの作成、変更、削除

ユーザーは「新しいものを作成するアクション」ではなく、「ユーザーをサインアップする」または「誰かのためにアカウントを作成する」アクションによって作成されます。ワークフロー（Runモード）でこのようなアクションを実行すると、「User」タイプの新しいモノが作成され、メールの一意性が検証されます。

‘Sign the user up’ アクションを経由した場合、ユーザーはパスワードを入力することができます。一方、’Create an account for someone else’ を使用した場合、ユーザーは ‘temporary password’ としてマークされ、Settings タブで関連パラメータを定義した場合は、パスワードを修正するように促されることになります。この設定により、まだ自分のパスワードを入力していないユーザーをリダイレクトするページを選択し、ユーザーが自分のパスワードを定義できるようなフォーム（関連するワークフローを含む）を構築することができます。リダイレクトはページロード時に行われ、’Log the user in’ アクションの後では行われません。

‘delete thing’アクションによってユーザーが削除されると、そのユーザーはデータベース上に存在しなくなり、ログインなどができなくなることに注意してください。

Current User

使用できる最も重要なデータソースの1つは、「現在のユーザー」です。これは、現在アプリケーションを使用しているユーザー（対データベース内の別のユーザー）を記述します。セッションは、ある時点でアプリケーションを使用しているユーザーの概念を記述するものです。技術的には、セッションは、ブラウザレベルでいくつかのクッキーによって定義されます。アプリの設定によっては、これらのクッキーに有効期限を設定することができます。一般に、このようなクッキーは無限であるため、ユーザーはログアウトするか、クッキーを消去するまで同じセッションにいます（Facebookと同様、ログアウトするか別のブラウザを使用するまで永久にログインしたままになります）。状況に応じて、現在のユーザーはサインアップされたものであったり、一時的なものであったりします。

登録されたユーザー(サインアップ)

ユーザーがBubbleにサインアップした場合（電子メールとパスワード付き）、この電子メールとパスワードを使ってデータベースに永久的なエントリーが作成されます。ユーザーが新しいブラウザでアプリを開き（Cookieなし）、ログインワークフローで資格情報を入力すると、そのユーザーはログインされることになります。Current user is logged in」の値は、「yes」を返します。現在のユーザーを変更した場合、その内容はデータベースオブジェクトに恒久的に保存され、ユーザーが別のデバイスでログインすると、そのアカウントに変更が適用されます。

この結果、データベース内の検索で見つかるすべてのユーザーは、サーバー上で「ログインしている」とマークされ、永久的なアカウントとなります。現在のユーザーを変更した場合、その内容はデータベースオブジェクトに恒久的に保存され、ユーザーが別のデバイスでログインすると、そのアカウントに変更が適用されます。

Bubbleアプリのエンドユーザーは、固有の電子メールアドレスを持っている必要があります。

一時的な利用者

ブラウザでBubbleアプリを開くと、すぐにユーザーセッションが作成されます。すでにログインしているユーザーがクッキーをクリアしていない場合は、以前と同じユーザーでセッションが行われますが、（ログインしていない）新しいセッションの場合は、一時的なユーザーが作成されます。このユーザーは「ログインしていない」とマークされます（言い換えれば、「現在のユーザーはログインしていません」はyesを返します）。

ユーザーが初めてアプリケーションにアクセスしたとき、そのユーザーは一時的なユーザーとして表示されます。もし彼らがサインアップワークフローを通過すれば、現在の一時的なユーザーはサインアップユーザーとなり、データベースに恒久的に保存されることになります。このことは、ワークフローの設計において、いくつかの重要な結果をもたらします。例えば、サインアップする前にユーザーに年齢を聞いて、それを「現在のユーザー」に保存するワークフローがあるとします。もし、そのユーザーが3日以内にサインアップすれば、その時に作成されるパーマネント・ユーザーはその「年齢」を持つことになります。

Oauth x でのログイン

ユーザー認証の最も一般的な方法は、パスワードや電子メールの入力を促すことです。しかし、外部サービスを利用して、別のサービスから得た認証情報を使ってユーザーを認証することも非常に多いでしょう。これは、プラグインによって行われます。そうすることで、アプリを設計する際にいくつかの利点があります。以下では、Facebookを例にして説明します（つまり、あなたのアプリは「Facebookでログイン」というボタンを提供します）。

・これにより、ユーザーはアプリに対してより迅速に認証を行うことができ、また別のパスワードを覚える必要もありません。通常、ほとんどのサービスでは、アプリに自分のIDを使用することを許可するための、簡単なワンクリックの認証フローが提供されています。例えば、「Login with Facebook」というボタンが1つ必要で、ユーザーはFacebookからアプリが自分の認証情報を使用することを承認するように促されます。

・また、ユーザーに代わってサービスを呼び出すことも可能です。Facebookの場合、Eメールの取得（Facebookに登録されている）、プロフィール写真の取得、ウォールへの投稿などを行うことができる。

Bubbleでこのようなフローを設定する場合、アプリが機能するためにユーザーに求める認証のレベルを定義する必要があります。デフォルトでは、ほとんどのサービスは、ユーザーがサードパーティのアプリケーションで認証情報を使用してサインアップしたときに、公開プロフィールとメールのみを公開しますが、より多くの権限（たとえば、相手のウォールに投稿する）を求めることができます。ソーシャルログインを使用し、必要な場合にのみパーミッションを求めるべきであることに注意してください。一部のデータへのアクセス許可を求めることは、ユーザーが敏感に反応し、サインアップの減少につながる可能性があります。

Bubbleでユーザーがソーシャルネットワーク（Facebook）にサインアップすると、従来のメールとパスワードによるサインアップフローと同様に、データベースに新しいユーザーが作成されます。主な違いは、一度ログアウトしたユーザーのログイン方法が、パスワードの入力ではなく、Facebookでのログインになることです（彼らはパスワードを定義していないため）。ユーザーがブラウザでFacebookにログインしている場合、アプリがFacebookログインを使用すると、ユーザーは自動的に現在のFacebookユーザーとしてログインされます。

従来のログインとソーシャルログイン

Bubbleのユーザーは、従来のログインとソーシャルログインを同時に使用することができます。ここでは、いくつかのケースを紹介します。

１．ユーザーが現在電子メールとパスワードでログインしている場合、Oauthプロバイダ（Facebook、Googleなど）とアカウントをリンクするように促すことができます。このようなフローを経由した場合、新しいユーザーは作成されませんが、代わりにOauth認証情報が現在のログインしているユーザーに追加されます。このフローが完了すると、ユーザーはメール/パスワードでログインするか、Oauthフローでログインできるようになります。外部サービスから提供されたメールアドレスを持つ別のユーザーがデータベースに存在する場合、このアクションは失敗し、ユーザーにメッセージが表示されます。

２．ユーザーがOauthフローを通過する際にログインしていない場合、新しいユーザーが作成されます。ただし、同じメールアドレス（Facebookに登録したメールアドレス）を持つユーザーがすでにアプリのデータベースに存在している場合は除きます。この場合、ワークフローは失敗し、ユーザーに対してメッセージが表示されます。

３．もしユーザーが外部サービスにサインアップしていて、自分のアカウントにパスワードを追加したい場合、「ユーザーのパスワードをリセットする」アクションを実行することでこれを行うことができます。これは、Oauth認証のみで認証していたユーザーを効果的に変更し、電子メールとパスワードの値をユーザーオブジェクトに渡します。

上記3が言及しているように、Bubbleにはアプリ内の既存ユーザーにOauthソースを追加する機能があります（例えば、エンドユーザーがアカウントを持っていて、メールとパスワードでサインインするが、Googleアカウントもリンクさせたい場合など）。
しかし、外部ソースによっては、この追加接続が微妙で、例えば、一定期間後にユーザーに再認証を要求する場合があります。特定のサードパーティを使用してテストしてください。

BubbleアプリをSSOプロバイダーとして利用する

バブルアプリは、多くのアプリやWebサイトで見られる「Facebookでログイン」機能と同様に、外部サービスやアプリケーションの認証プロバイダーとして利用することができます。

・BubbleアプリをOAuthプロバイダとして利用する場合、https://[Your-App-URL]/version-test/api/1.1/oauth/authorizeにclient_idとredirect_uriをパラメータとしてGETコールが行われるようになります。

・これが成功すると、URLのパラメータ “code “が外部サービスへ返されます。

・次に、外部サービスは https://[Your-App-URL]/version-test/api/1.1/oauth/access_token への POST 呼び出しをパラメータ付きで実行する必要があります。「client_id”、”client_secret”、”redirect_uri”、”code “をパラメータとしてPOSTコールを実行します。これはトークンエンドポイントとして知られています。

・最後に、アプリは外部サイトがユーザーに対して保存できる「access_token」、「expires_in」、「uid」パラメータで応答します。

・access_tokenは、今後、外部アプリ内のユーザーからBubbleアプリを呼び出す際に使用されます（有効期限あり）。

・トークンのリフレッシュ: POST 本文で grant_type を “refresh_code” に設定し、前回受け取った refresh_token と同じリフレッシュトークンを送信します。このとき、トークンを最初に取得したときと同じclient_idとclient_secretを含める必要があります。

Oauthに関するQ&A

Oauthに関連するよくある質問

Bubbleアプリにすでに存在するユーザーに、新しいOauthサービスをアタッチするにはどうすればよいですか？

ユーザーがすでにサインインしている場合、Oauthサービスで「ソーシャルネットワークでサインアップ/ログイン」を使用すると、そのユーザーのサービス上のアカウントとBubbleアプリのユーザーレコードが「リンク」されます。

リフレッシュ・トークンは自分で処理する必要がありますか？

一般的に、Oauthログインを提供するプラグインを使用している場合、そして使用しているプラグインがこの機能を備えて設計されている場合（ほとんどの場合、そうです）、「いいえ」です。

リフレッシュトークンの処理が必要になるケースとして、Oauthを有効にするために独自のプラグインやAPI接続を構築している場合があります。例えば、アプリでユーザーを Google に認証させ、Google のデータを使ってユーザーに代わって何かを行うことができます（例えば、ユーザーがアプリでアクティブかどうかにかかわらず、X 時間ごとにメールをチェックするなど）。このような場合、Google Oauthを提供するプラグインだけでは不十分で、自分で構築する（あるいは別のプラグインを探す）必要があるかもしれません。独自のプラグインやAPI接続を構築する場合、特にGoogle用のリフレッシュトークンをどのように処理するかを示すドキュメントを以下に示します。

https://developers.google.com/identity/protocols/oauth2/web-server#offline

Oauth経由でサインアップしたユーザーが自動的にログアウトしてしまうのですが、どうしたらいいですか？

Oauthログインは、エンドユーザーのセキュリティを向上させるために自然なタイムアウトを持つことがありますが、これは通常、数日またはそれ以上の大きさのオーダーです。もし、ユーザーが短期間ログインできない場合は、リフレッシュ・トークン（Oauthの権限付与が時間経過とともに自動的に更新される仕組み）に何か問題がある可能性があります。

これらの問題は、使用しているプラグイン（またはAPI接続）、またはサードパーティ自体の設定に何か問題があることが多いため、デバッグするのが難しい問題です。同じサービスでOauthを提供する別のプラグインをインストールし、その新しいプラグイン経由でテストユーザーにサインアップして、そのユーザーで同じ問題が発生するかどうかを確認するのもひとつの方法です。それでも解決しない場合は、フォーラムでその特定のOauthプロバイダーの問題を解決した他のユーザーを確認することができます。

あるOauthサービスで使用するプラグインを切り替えても、そのサービスでログインするすべてのユーザーの能力を維持できますか？

同じOauthサービスの異なるプラグインは、Bubbleによって事実上異なるOauthサービスのように扱われます。例えば、プラグイン1とプラグイン2が両方ともGoogleでサインアップ/ログインできる場合、1から2に切り替えても、すべてのユーザーがGoogleでログインする能力は自動的に維持されません。

この移行を処理するために、プラグイン1から2に移行したいとします。少しの間、アプリに両方のプラグインをインストールしておいてください。ユーザーが（プラグイン1経由で）ログインしたら、プラグイン2の「Signup/Login with a social network」アクションを持つワークフローをキックするように促します – これで2のOauthサービスがユーザーと関連付けられます。すべてのユーザー、またはほとんどのユーザーがこれを実行した後、プラグイン1を削除しても大丈夫です（まだ残っているユーザーは、パスワードのリセットフローでいつでも自分のアカウントにパスワードを追加できます）。

参考英語サイト

https://manual.bubble.io/help-guides/working-with-data/authenticating-users

参考英語動画サイト