
    <div>
      <a href='/'>MENU</a>
    </div>
    <style>
    body {
      font-family: monospace;
    }
    </style>
    <style>
.shiki {
  padding: 12px 8px;
  border-radius: 8px;
}
</style>
    <pre>
  <pre><code>* OpenID Connect (OIDC) = OAuth 2.0 + thin authentication layer (the thin auth layer provides ID token and /userinfo endpoint etc)
* OIDC is used to implement &quot;Sign in with Google&quot;, &quot;Sign in with GitHub&quot; etc.

* OAuth = &quot;I grant this app permission to use my XYZ data&quot; where XYZ is some service like google drive, youtube, google calendar, spotify etc
* OIDC = &quot;I prove that I am me&quot; (an identity layer built on top of oauth 2.0)

* When you make a request with &quot;scope=read:contacts&quot; you&#39;re just using oauth 2.0 for &quot;delegation of access&quot;
* When you make a request with &quot;scope=openid email profile&quot; you are using oidc and you&#39;ll get an ID token back

* client_id&#39;s are issued to applications/servers/services by an IdP

* (iss,sub) identifies a user but many authorization servers will generate a &quot;pairwise id&quot; in sub based on user (identity + client_id) meaning if the same user obtains tokens for both serviceA and serviceB these tokens will contain different &quot;sub&quot; values even if both ids refer to the same actual user (this prevents third-parties from trying to collude/track user behavior cross services)

* xh https://COMPANY_NAME_HERE.okta.com/.well-known/openid-configuration


# Enterprise SSO

* When using federated identity, an app can act as a SAML service provider (SP) or an OIDC &quot;relying party&quot; for other (customer) IdP&#39;s.

* If you have your own little IdP you need to add support to &quot;handle inbound federation&quot; (i.e. implement SAML or OIDC).

* When a customer from customer enterpriseX navigates to the app, we look them up using domain/email and determine that this customer has SSO configured via their own IdP and we then redirect to the customer IdP for the login process. Our app is configured as an application in their IdP. Their IdP sends back either an SAML
assertion or an OIDC ID token (we validate these, determine user access level and issue an appropriate access token for them to use inside our app). You can add
this support via passport-saml and other similar packages.

* Auth0 has been rebranded as &quot;Okta Customer Identity Cloud&quot;. When you use a professional IdP you get &quot;self services pages where each customer can input and update their SSO details like their issuer URL, their cert etc.

* WorkOS, BoxyHQ, Ory, AWS Incognito, Azure Entra ID are alternatives to Auth0/Okta.

* SAML is notoriously difficult to implement securely. XML parsing vulnerabilities (like XXE, XML External Entity Injection) are common.

---


# Keycloak

* Start an Keycloak server using:
docker run --rm -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=$(cat ~/.some-password) quay.io/keycloak/keycloak start-dev
</code></pre>