組み込みのUser Typeを使用すると、アプリでユーザー認証を処理することができます。ユーザーは、メールアドレス、または外部サービス（Facebook OAuthなど）を通して認証される場合はIDによって一意に定義されます。
Contents
ユーザーの作成、変更、削除
ユーザーは「新しいものを作成するアクション」ではなく、「ユーザーをサインアップする」または「誰かのためにアカウントを作成する」アクションによって作成されます。ワークフロー（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に関連するよくある質問
参考英語サイト
https://manual.bubble.io/help-guides/working-with-data/authenticating-users
