Oso Onboarding Day 1

Things you Auth to know

100

This is the difference between Authorization and Authentication

AuthZ: who you are

AuthZ: what you can do

200

A metaphor for the difference between Authorization and Authentication

1. AuthN: get in the house
2. AuthZ: what rooms can you open, etc.

300

An example in SalesForce of the difference between authorization and authentication 

Authentication: You log into SalesForce and SalesForce knows you are you

Authorization:

1. SalesOps admin can add users; you can’t
2. You can only see the accounts and opportunities you own
3. But your manager can see opps and accounts for everyone on the team
4. Maybe analysts can see all data but can’t change anything

400

An example in an app that we did not discuss during training of the difference between authorization and authentication

[up to Marci]

500

4 Keywords to listen for that tell you you're talking about Authorization

1 Keyword to listen for that tell you you're talking about Authentication

RBAC, roles, permissions, access control, ReBAC, ABAC

SSO, LogIn, SCIM

FeatureZ

100

4 Features powered by Authorization

Custom Roles

Collaboration

Entitlements 

Fine-grained Authz

200

Most common first step to authZ (with an example)

Coarse roles

Example: members can do some things, Admins can do everything

300

Common AuthZ change when companies move upmarket (with the definition & an example)

Fine grained authorization

Shift from feature -> object

Example: 

1. Reps can view accounts —> this rep can view these 50 accounts
2. “Accounts” is the object/resource
3. All reps have access to the feature to view accounts, but now they can only see the accounts they’re assigned

400

Enterprises want this to determine the definition of roles themselves

Example:
I want a separate billing admin, which can only change billing info

Custom Roles

500

Allows enterprises to only give customers features that they signed up and paid for

Entitlements

Architecture 101

100

This is where the actually data lives — actual account names, actual contact names, etc.

Database

200

1. This is the thing you see and click
2. These days, it’s usually in your browser, maybe a mobile app
3. This is all visual stuff — buttons and letters and tables and pages

Frontend

300

1. This is what takes over once you start clicking on things
2. It’s all the logic and mechanisms that, behind the scenes, actually kick off work when you click on something
3. E.g., Clicking on “New Opportunity” opens a new page with a form to fill out

Backend

400

Walk through the 3 key pieces of any app with SalesFore as an example

1. Frontend: button that says “new opportunity”
2. Backend: logic that says “when users clicks this button, open a new page with a form on it for them to fill out about the opp”
3. Database: then you click “save” and all that data goes into the database, neatly organized and ready for the next time you want to go back and view the opp data you just entered

500

the thing that gets sent through an app when you press a button/open a page to make something happen

Request

AuthZ-itecture

100

How authorization fits in on the frontend

needs to check features i have access to so they know what buttons to show / grey out

200

How the backend fits into authorization

Needs a way to check if I’m allowed to do the thing I’m trying to do

300

How a database fits into authorization

this is where all the data that drives authz decisions actually lives, e.g., what accounts you own, whether you’re an admin or a member

400

Walk through how an authorization request would flow through 3 key pieces of any app with SalesFore

Frontend - I see an opp and I want to click it and learn more 

Backend - can this AE see this opp?

Database - has a piece of data that says this AE is the owner of this opp

500

Explanation for why Authorization is on the critical path

1. Every time you click a button or open a page or interact with the app in any way, the app needs to check if you’re allowed to do the thing you just tried to do; it also may need to enforce some authorization when it shows you the result of whatever you asked for, e.g., maybe you ask for a report of all “your” accounts — it needs to know what those accounts are so it can show you only those accounts when it renders the list on the screen
2. This means that whatever your authorization solution is, it must be FAST and it CANNOT GO DOWN

misc.

100

Difference between Monoliths & Microservices

The app is split into separate services with different databases

200

Difference between Okta and Auth0

Internal Employees (Okta) vs. Customer Facing (Auth0)

300

Difference between Oso & ConductorOne

Internal Employees (ConductorOne) & Oso (External Employees)

400

% of time the system responds to your requests

Uptime

500

how long it takes to respond to your request

Latency/Performance