Authentication is pretty simple when you first get started. Signup, login, password reset… maybe social login integrations or 2FA if you want to add some frills. Many frameworks have these features out of the box, and they may only take a little while to implement. Unfortunately… things often don’t stay simple, especially once you start to sell to larger companies or your existing customers start to see growth. In order to better understand this, we’re going to follow the journey of a fake company, **Acme.** We’ll also pretend we are building a B2B SaaS application, **Circular** \- it’s a cool new project management tool designed to help companies track and organize their tasks. ## Acme is founded **Acme** is founded. There’s two founders, a CEO and a CTO. The CTO signs up for an account with **Circular** and creates an organization called **Acme.** ### What auth features are needed? At this point, the CTO is using **Circular** alone, and the only real auth feature that **Acme** cares about is just plain old signup and login. This could be via passwords, passwordless, social logins, etc - the only thing that matters is that they can create and log in to their accounts. ## Acme hires their first employee A new employee joins **Acme**! This new employee needs access to **Circular** to coordinate with the CTO and track their own tasks. The CTO goes in to **Circular** and invites the new employee. The new employee accepts the invitation and now has access to all of **Acme’s** data within **Circular**. ### What auth features are needed? The new auth features that **Acme** cares about are the concept of an organization and the ability to invite employees to that organization. The concept of an “organization” or “tenant” will be important for ownership of the data. All employees in the **Acme** organization within **Circular** will be able to see **Acme**’s data. As employees are added to the organization, they will get access to all of **Acme**’s tasks within **Circular**. ## Acme hires a few more employees **Acme** is growing, and so is their usage of **Circular**! Every new employee is added to **Circular** as part of their onboarding. As they grow, the CTO gets a little worried about what permissions each employee has. A new hire mistakenly deleted one of the CTO’s tasks thinking it was one of their own (it happens). As a result, the CTO goes through and sets all employees roles to **Member**, leaving themselves and the CEO as **Admin** s. ### What auth features are needed? As **Acme** grows, they need a bit more control over what each of their employees can do. Very commonly for B2B applications, this is done via **Roles** and is part of a broader class of problems called authorization. ## Acme grows to 50 employees **Acme** is a rocketship! It seems like just yesterday they were two people working out of an apartment in SF, and now they have 50 employees. On most weeks, they are onboarding at least one new employee. They still use **Circular**, but they now have a lot of other products they use as well. New engineers are added to Github, AWS, PropelAuth, Notion, a few different AI-powered IDEs, and, of course, **Circular**. New members of the sales team have their own set of tools. New members of the support team have a different set of tools. It’s a headache to go to each tool and manually invite the new employee. Even worse, when employees leave, someone at **Acme** has to remember all the different tools they were given access to, and make sure to revoke their access. Luckily, **Acme** isn’t the first company with 50 employees, and this is often where services called **Identity Providers / IdPs** (e.g. Okta, Entra, OneLogin, etc.) come in. Every **Acme** employee gets an account with an Identity Provider, and they use those company-provided accounts to log in to all the different products they use. This allows **Acme** to manage who gets access to what in one central location. ### What auth features are needed? This section requires **Circular** to provide an additional authentication method, often called Enterprise SSO (also called SAML or OIDC, which are implementations). This authentication method allows **Acme** to set up a login flow just for their employees - their internal IT team will be able to control who can use it. Optionally, **Acme** may want SCIM provisioning support as well, which will allow **Acme** to notify **Circular** immediately when a change is made to one of their employees accounts. ## Acme is now hundreds of people If managing employees access to products was hard at 50 people, it’s dramatically harder with hundreds. This is where the story gets more open ended. The biggest consequence of being this large is that **Acme** is often able to request custom features from the products they use. Sometimes this means **Acme** needs **Circular** to let **Acme** create more granular roles than **Circular** currently supports. Sometimes this means **Acme** needs **Circular** to have shorter session durations for their employees. Sometimes this means **Acme** needs detailed usage audit logs from **Circular.** Sometimes this means **Acme** prefers to self-host **Circular**. ## Who should own these features? Authentication can sit in a pretty strange place in a company’s priority list. It’s obviously important for onboarding new customers, and it can truly make or break Enterprise deals with security-conscious stakeholders. However, it’s also not something that obviously pushes the mission of the company forward. Diverting resources to it will likely divert resources away from something more core to the company’s value proposition, unless you’re lucky enough to be a company large enough to have a dedicated Identity team. For some companies, the diversion of resources is the right choice. They want complete ownership over their authentication and onboarding flows, and they’re comfortable with the tradeoffs. For others, seeking an outside authentication provider makes more sense. No need to reinvent the wheel or pull engineers away from other tasks to deal with auth or user management bugs. ## We’re an auth provider You may have noticed that we, [PropelAuth](/content/?ref=propelauth.mymidnight.blog), are in fact an authentication provider ourselves. This is the part where we tell you we have everything you need to tackle all of **Acme**’s needs, and more. Our customers are using PropelAuth to close deals with companies like Hubspot, PWC and Adobe, and flying through their security checklists with ease. If you’re interested, we encourage you to [check out our docs](https://docs.propelauth.com/?ref=propelauth.mymidnight.blog) or [schedule a call](https://calendly.com/andrew-propelauth/propelauth-integration-chat?ref=propelauth.mymidnight.blog) to chat through your needs!