Building your own Single Sign-On (SSO) for an empire of products.

James Kenny -

For a while, I've had the goal of creating multiple products. The many small bet idea. In one way it lets me spread my chances that one of my products will take off but also what if a few do?

I decided to join Audience and Contentr into a suite. Audience is an email marketing tool and Contentr is a content marketing tool. There is some overlap in both tools and they can complement each other well.

My idea is that you can have an account on either, but also upgrade to a suite account and get access to both tools.

Building Single Accounts

I've tried to keep this as simple as possible for me.

I have 3 databases:

  • WebusersDB
  • ContentrDB
  • AudienceDB

In the WebusersDB I have the tables for my user logins. 

    TABLE [User](
	[UserId] [nvarchar](450) NOT NULL,
	[Email] [nvarchar](256) NULL
	........

My naming on these tables is just next-level!!

Then in both, the AudienceDB and ContentrDB databases I have the tables

    TABLE [Tenant](
	[TenantId] [int],
	[Name] [varchar](256)
	........
    
    
    
    TABLE [TenantUser](
        [TenantUserId] [int],
        [TenantId] [int],
        [UserId] [nvarchar](450)
        ........

When a user logs into Audience, I validate the login against WebuserDB.User

If they are valid, then I check the AudienceDB.TenantUser table. If the user is there they log in and carry on. If they are not then I send them to the onboarding flow.

TenantUser

I use a TenantUser table to store the WebuserDB.User.UserId and the TenantId this way in the future if I want to allow users to add multiple users I don't have to do a lot of reworking of tables.

A big benefit I've found from using this is that every time I create a new product even something for fun, I have my login already done. I just use the existing databases and schemas.