SKILL.md
Netlify access control — pick the protection layer
This skill routes you to the correct protection layer. It does not teach each one. These settings have no public API, CLI command, or MCP tool. Never curl api.netlify.com or read local auth tokens to inspect or change them — give the user the dashboard path and checklist. On failure, report what you tried and stop.
First: disambiguate "auth" — three unrelated layers
Users constantly conflate these. Identify which one is meant before recommending anything.
- Netlify Identity — "who is this user inside my app." Issues
nf_jwt. → route to the netlify-identity skill; not covered here. - Password Protection / project visibility — "can this request load the site at all." Covered here.
- Team/Org SAML SSO — "can you log in to the Netlify dashboard." Gates dashboard access; also underlies team-login site protection.
Sessions are separate. The same provider (e.g. Google) can appear twice unrelated — Identity OAuth for app users vs. SAML IdP for team members.
Double-login footgun: a Password-Protection/team-login perimeter session and an Identity app session have no bridge — no shared cookie, no header forwarding, no JWT exchange. Don't try to wire them together. For the combined layered pattern and its tradeoffs, see references/two-layer-pattern.md. The Netlify login itself does reach app code: on a private project or with team login protection, functions and edge functions receive the signed-in Netlify user as context.user — if every app user can pass that login, it is the app's identity and no second login is needed.
Want an internal app with a single sign-in (no double login)? First ask who uses it:
- They can pass the project's Netlify login → Private project (Credit-based plans; Pro for anyone beyond the Team Owner) or team login protection (Enterprise), and use
context.userin functions for per-person behavior. - They can't (e.g. employees without Netlify seats) → Auth0 extension federating to the corporate IdP, before the two-layer stack.