Max 8base Users on Developer Plan

I don’t see any info on the pricing page around how many 8base native users (without bringing your own auth provider) are allowed. It’s 5 on the free plan but not seeing any info on how much for the paid plans. Does anyone know? Is it pay per user, etc.?

Also, outside of Auth0, are there other providers that the community would suggest? Auth0 is pretty expensive from what I’m seeing.

Hello!

You can have an unlimited number of users on “Professional” plan.

You can find all information about pricing here:

About other providers:

You can try our default auth profile based on Amazon Cognito besides Auth0.

Please let me know if you have any questions.

Lada Kokotova | Technical Support Engineer

Thanks for the answer, @lada.kokotova! Couple quick clarifications.

  1. When using your own auth provider (auth0, okta, cognito, ect.) 8base only counts users as database rows, like any other record. We do not track the number of users stored in your auth providers database, which hypothetically means you can have unlimited users there. However, let’s say your plan 8base plan included 1,000,000 DB rows, you could have a total of 10,000,000 records in your database, inclusive of user records.

  2. When using 8base Authentication (Cognito behind the scenes), we encourage you currently only to use this as a development solution, as the emails that get sent and such are not customizable for client facing applications. That said, we’re roadmapping improvements to auth which will expand upon this service, where then a 3rd party auth provider isn’t required.

  3. You can use any 3rd party auth provider that’s openID compliant. Auth0 is easy to set up, but pricy. Cognito is a killer deal, but sometimes tricky to implement! We’re planning out our content calendar, so let us know which services would be most valuable to have tutorials around.

Thanks!

1 Like

@sebastian.scholl thanks for the in depth review here. If you have any info on the cognito approach that would be super helpful! I’m relatively new to AWS so any help in wiring that up to 8base would be awesome.

Thanks!

Cool beans. Noted! I’ll try to get a video done sooner than later on that.

Just checking in here. Wondering if there’s any docs, tutorials, or videos helping walk through the approach you outlined @sebastian.scholl ?

I’m literally going to the studio today to do a video run through! That said, here’s a PDF version of the tutorial to get you going: PDF Host - Edit

1 Like

Awesome, thanks for the video, been going through and looking to set it up. That said, I’m not entirely sure I understand the flow at the end of the video. You’re signing up a user, shouldn’t that not need a bearer token, since the user would only receive the token once they have an account? I would imagine you use the bearer token in the header when trying to access user specific data. Am I misunderstanding?

Hmm, looks like I’m misunderstanding. With OpenID providers you need to do a two step process - create the user via API w/ Cognito and then separately submit that token on the userSignUpWithToken route. I imagine the best setup here would be some sort of endpoint within 8base that handles this for you in one route. Separately, for the sign in process you hit Cognito to get the token and then you set that as a header for your calls to 8base giving you access to that user’s data. Is this right?

Looks like I was wrong again and that this image shows the flow. In practice, I’m looking to use SvelteKit and unfortunately there aren’t any demos on that framework. I’m trying to leverage the Vue example but am not fully understanding how it all works. Here’s my understanding so far, wondering if I’m on the right path:

  • Authenticate user via Cognito and get the idToken
    • if user doesn’t exist yet then you create the user via signUpUserWithToken method in 8base
  • Set the headers to include the idToken in all calls to 8base
  • All calls to 8base now respect the user and will only serve records that user should be able to see

Is that basically correct?

That is the flow!

Think of the Bearer token as a session token (it expires) that gets sent with every API request as an Authorization Header.

Yes, your breakdown is correct! I really haven’t played with SvelteKit unfortunately, however the concepts stay the same.