Back to Skills

oauth

Configure OAuth providers (Google, Apple, Microsoft, Facebook, GitHub, etc.) to work with portless local dev URLs. Use when setting up OAuth redirect URIs, fixing "redirect_uri_mismatch" or "invalid redirect" errors, configuring sign-in providers for local development, or when a provider rejects .localhost subdomains. Triggers include "OAuth not working with portless", "redirect URI mismatch", "Google/Apple/Microsoft sign-in fails locally", "configure OAuth for local dev", or any task involving

9,760stars310forksUpdated 6/15/2026

Security Assessment

Medium Risk(60/100)

Detected risks:

Sensitive File Access([SKILL.md] .env)
Privilege Escalation([SKILL.md] sudo)
Security Score60/100

About oauth

The OAuth skill solves a critical problem developers face when configuring OAuth authentication providers for local development with portless domains. When using portless with the default `.localhost` TLD, major OAuth providers like Google and Apple reject redirect URIs because `.localhost` subdomains are not recognized in the Public Suffix List or are explicitly blocked by provider policies. This causes "redirect_uri_mismatch" and "invalid redirect" errors that prevent sign-in functionality from working locally.

The skill provides a straightforward solution: use portless with a valid TLD from the Public Suffix List (such as `.dev`, `.app`, or `.com`) instead of `.localhost`. By running `portless proxy start --tld dev`, developers can serve their applications on domains like `https://myapp.dev` that OAuth providers recognize and accept. The skill includes specific configuration guidance for each major provider, explaining their validation rules and showing exactly how to set up authorized redirect URIs.

This skill is essential for full-stack developers and teams building applications with social sign-in features. It addresses authentication setup for Google, Apple, Microsoft, Facebook, and GitHub OAuth providers. The guidance covers both individual developer workflows and team configurations, including recommendations for using subdomains of owned domains (like `myapp.local.yourcompany.dev`) to prevent DNS collisions and enable wildcard DNS records for team-wide consistency. The skill is particularly valuable when dealing with strict providers like Google and Apple that have rigid localhost policies.

FAQ

Why do OAuth providers reject .localhost subdomains?

Most OAuth providers validate redirect URIs against the Public Suffix List. Google rejects .localhost subdomains because they're not in their bundled PSL, while Apple rejects localhost entirely. Using a recognized TLD like .dev or .app ensures the domain passes validation checks.

Which TLD should I use with portless for OAuth?

Any TLD in the Public Suffix List works (.dev, .app, .com, .io, etc.). For best practices, use a subdomain of a domain you own, like myapp.local.yourcompany.dev, to prevent DNS collisions and enable team-wide wildcard DNS records.

Do I need HTTPS for OAuth with portless?

Yes, HTTPS is required for TLDs like .dev and .app which are HSTS-preloaded. Portless handles this automatically with the --https flag when you use these TLDs.

Which OAuth providers work with localhost?

Microsoft and GitHub are permissive and allow both localhost and .localhost subdomains. Google allows bare localhost but rejects .localhost subdomains. Apple rejects all localhost usage entirely. Facebook allows localhost but requires exact URI registration.

Will portless domains work for team development?

Yes, by using a subdomain of your company domain (like local.yourcompany.dev) and setting a wildcard DNS record pointing to 127.0.0.1, every team member can use the same portless configuration without manual /etc/hosts editing.

Install oauth

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill