Beyond Identity and Bubble


Hi, my name is Raj and I'm an engineering manager at Beyond Identity. And today I'm going to show you our, a secure application where you can use Beyond Identity secure customer passwordless authentication solution to authenticate the users to your app. First off, is one of the leading providers of hosted no-code applications that are quick and easy to create for developers and for non-technical folks alike. 

I was able to get started with Bubble in about two hours during one of our company hackathons. So, about Bubble. It has a robust community of developers creating plug-ins and creating applications. So, people can create a fully functioning web app within minutes using your plugins, other companies, and people's plugins or any combination thereof. 

It's very easy to use. So, we're creating this video today to show you our web app and our plugins. At the end of this video, you'll be able to deliver a seamless passwordless authentication experience to the users of your application. We have documentation to support this that you can look up and refer to at any point. I'll show you that as well. 

All right. First off, I'm going to show you a demo web app. All our users need to sign up is their name and their email address. That is enough information to create an identity. So, my name is Raj. I'm going to put my name here. I've done this a few times, so I'm going to use something to differentiate my name. 

And I'm just going to give my email address here. When I hit Sign Up and Bind a Passkey, this is going to go to the backend and create my new identity and it's also going to request a passkey binding email. So, I'm going to go to my email box, I'm going to look for it. 

Here's that passkey binding email. It's got my name, the thing that I just created. When I hit Complete Registration here, it's going to send me over to BI. You probably can't see this, but it's asking me for the biometric step-up on my Mac. So, I'm going to put my finger on the fingerprint reader right now. That verifies that it is really me who's using this machine. 

That's something that we manage between us and the operating system. And now I am logged in. Here's my username right here. The next time I want to log in… I'm going to log out right now. The next time I want to log in, I'm just going to paste that same email address that I used. And when I hit Login, it's going to go back to Beyond Identity. It's going to ask me which of my credentials I want to use. 

As you can see, I've done this a few times in the past. Right now it's asking me for my biometric step-up. I'm going to put my fingerprint on the reader. It's verified my identity now. It's quite quick. And now I'm logged in again. This is what your users can experience. 

They can set up different passkeys per device. And it's quite flexible. So, they can have a passkey on their mobile, on their tablet, on their laptop, and quite flexible. All right. You might be asking yourself, "How do we do this?" Let me show you the web app and how it works beyond the scenes. We have in our Bubble account, we have two plugins. 

This is the Beyond Identity Customer Management plugin. This is what you use to create an identity. Your web app would say, "Here's the name of my new customer and their email address. Please create an identity within my Beyond Identity application for them. And then in the future, help them bind a credential." 

You can bind a credential either via link or via email like I did a moment ago. The second is the Beyond Identity Customer Authentication plugin. AuthN is short for authentication. This is using's OAuth plugin. So, there's not much code behind this. 

There's mostly just OAuth configuration. So, let me show you how these plugins are used within the app. This is the app here. First, let's dig into what happens when you click Sign Up and Bind a Passkey. Everything in Bubble goes by workflows. So, this is the workflow for right here when Sign Up and Bind a Passkey is clicked. First thing we do is sign the user up. 

This basically just puts a row in Bubble's local database. This person has signed up, not much more than that. The next thing we do is create the user with the customer user management plugin. This has some of the parameters that you will discover in our guide how to create and retrieve these parameters. It's going to use the email address that the customer input, the display name that they input, and it's going to reuse the email address again as a username. 

It's going to take that and create the identity. That identity will not have any credentials bound yet. Credential is synonymous with passkey. The second thing it'll do is it will send a passkey enrollment email. We'll use some of the parameters that we've already seen. It'll use the identity ID that was generated in step two here, and it will redirect. 

It'll use this as the redirect URI to redirect back to our app when we're done. And it'll use an authenticator config ID, which is also described in our guide. When it's finished, it'll go to a page called the Credential Bound page. This is just a second page that I have created in our app. And that page simply has…it simply says, "Created a new identity and sent a passkey binding email. Please check the email to bind a new passkey." 

And it'll display the email address here. Okay. So, that's it. I want to show you the login flow now, which is slightly simpler. Here's the login flow. So, when someone clicks, it'll log the user in, which is updating that local Bubble database route. And then it'll use the BI Secure Customer Authenticate, which, again, is our OAuth plugin. 

And that will show up here, BI Secure Customer Authenticate. And you have to provide very, very few parameters to those. It just knows how to OAuth. And that is the entire flow. I want to walk through some of the high-level constructs for you all, a few things like identity, passkey, the enrollment flow, and the sign-in flow that we can see here. 

So, an identity, that's really just me and my email address. Each person should have their own identity. I wouldn't suggest doing this for groups of people like with a Google group or anything like that. Each identity should be an individual with their own email address. The next construct is the passkey. 

Each identity can have multiple passkeys. I can have one for my laptop, one for my phone, one for my tablet, what have you. There's no limit to those. You want to keep those well-managed, of course. You don't want those flying around. But that gives you the flexibility to have multiple devices enrolled for every user. Next, the enrollment flow. 

That starts with this box here, sign the user up, which basically just inserts a row into's local database and moves onto the next step. Then it creates the user. So, this does an API post to our endpoint, which says, "Here is the user name, and here is their email address. Please create this identity in the BI application that you've created." 

And that will return an identity ID. And we'll use that in the next step, which is send a credential/passkey enrollment email. Credential and passkey is synonymous. That will send a passkey binding email to your email address so that you can click on it and bind the passkey to your device. 

There's an alternative here. If you've authenticated the user another way and that user may not have access to their email box at the moment, you're confident that the person is who they say they are, in your app, you can display a passkey binding link so your user don't have to go jump out to their email client, go look for an email and click on the link. 

You can just display the link directly within your app and they can click it and bind the passkey via the native browser. And then go onto the next page, which is a success message or a message that says, "Go check your email." The sign-in flow is much the same in the login here. We use OAuth. OAuth will redirect to a Beyond Identity page where all of our policy checks are triggered. 

Again, that includes the step-up if the admin requests it and then allows or denies that authentication request. I'm going to show you the two plugins that we have. The customer management plugin and the authentication plugin. 

The customer management plugin is the one that creates the identity and sends the credential-binding email. And the second one is the AuthN plugin. That's the OIDC client, the OAuth OIDC client. The last thing I want to show you is our documentation on how all of this flows together. This shows you how to create your own web app in Bubble and how to use our plugins and also how to find our information here. 

If you visit, or if you just go to Guides, you can find us here at along with other things like WordPress and a few others that are coming. Thanks for watching.