# Using Identity Providers — Authentication & Authorization

Source: https://www.skillbyai.com/en/authentication/x-idp

> Build versus buy.

## What an identity provider gives you

An **identity provider (IdP)** handles sign-up, login, MFA, passkeys, social login, password resets, token issuance and admin tooling, usually via OIDC and SAML. Options include managed services such as **Auth0** (Okta), **Amazon Cognito**, **Firebase Authentication**, **Microsoft Entra ID** and **Okta**, and self-hosted open source such as **Keycloak**. **Buying** shifts security-critical work to specialists and speeds up enterprise features (SSO, SCIM provisioning); costs include per-user pricing, vendor lock-in, and less control over UX and data residency. **Building** gives control but makes you responsible for every flow in this course. A common middle path: use an IdP for authentication, keep **authorization** and user profile data in your own application. Features and pricing change often; check each vendor's current docs.

## Running identity for real

In production you choose identity providers, watch auth events, manage machine credentials and review the whole system.

![Four ideas: identity providers, auditing and monitoring, API keys and service accounts, a final checklist.](assets/figures/authentication/section-8-map.svg) — Figure 8.1 — Provider, monitor, machine identity, review.

## Build or buy: a decision sketch

Questions to weigh.

```text
lean towards an IdP / managed service when:
  - you need MFA, passkeys, social login or enterprise SSO (SAML/OIDC) soon
  - the team has little identity security experience
  - compliance requires audited, well-maintained auth flows

lean towards building (with vetted libraries) when:
  - requirements are simple (one app, email + password + passkeys)
  - strict data residency or offline/on-prem constraints rule out SaaS
  - per-user pricing does not fit your scale

self-hosting (e.g. Keycloak) sits in between:
  you control data, but you operate, patch and scale it yourself
```

## Keep your user ID independent

Store the IdP's (iss, sub) in an identities table that maps to your own user ID. Migrating providers later then means re-linking identities, not rewriting every foreign key.

**Quiz:** Which is a common trade-off of using a managed identity provider?

- [ ] It prevents all phishing automatically
- [ ] It removes the need for authorization in your app
- [ ] It makes HTTPS unnecessary
- [x] Vendor lock-in and per-user costs in exchange for less security work

*Answer:* Vendor lock-in and per-user costs in exchange for less security work. IdPs handle authentication; your app still owns authorization.