authentication

Bilingual

What DMARC Protects You From, and What It Does Not
2 months ago
- DMARC's actual scope is narrow: it only verifies whether the visible From domain authorized a message through aligned SPF/DKIM, not spam or phishing.
- Three key terms: SPF lists authorized sending servers, DKIM provides a cryptographic signature, and DMARC ties either back to the visible From address.
- Email has two 'from' addresses: envelope for routing and visible From for display; DMARC ensures authentication aligns with the visible one.
- DMARC records live in DNS; examples show SPF, DKIM, and DMARC record syntax.
- A DMARC pass requires either SPF or DKIM to authenticate and align with the visible From domain; relaxed mode allows same organizational domain, strict requires exact match.
- DMARC does not inspect content—only provenance, leaving body, links, attachments, and intent unverified.
- DMARC effectively stops exact-domain spoofing and provides aggregate reports to discover unauthorized senders.
- DMARC fails to address lookalike domains, display-name impersonation, compromised mailboxes, authenticated malicious domains, spam filtering, and breaks with forwarding/mailing lists.
- A DMARC pass confirms authorization, not trustworthiness; vendors overstating its phishing prevention leave users exposed.
- Proper DMARC enforcement requires careful monitoring and remediation, not a blind switch to p=reject.
Announcing License Key Authentication
2 months ago
- Keygen introduces license key authentication as a simpler alternative to activation tokens.
- License key authentication allows API authentication using a license key instead of a token.
- Users can set a policy's authentication strategy to LICENSE to use license keys.
- License keys enable API requests like machine activation, release downloads, and heartbeat pings.
- License tokens remain supported for fine-grained access control when needed.
- A MIXED authentication strategy is available to handle migration from tokens to license keys.
What's the best way to do authentication in modern applications
2 months ago
- JWTs are commonly used for authentication but storing them in localStorage makes them vulnerable to XSS attacks, as any JavaScript on the page can read localStorage.
- Using HTTP-only cookies with flags like Secure and SameSite=Lax prevents JavaScript from reading tokens, reducing the risk of token exfiltration during XSS attacks.
- CSRF attacks are a risk with cookies, but can be mitigated using CSRF tokens, SameSite attributes, and checking request headers like Origin or Sec-Fetch-Site.
- Stateless JWTs have revocation issues; server-side sessions with opaque session IDs in HTTP-only cookies allow immediate session invalidation and are more secure for single applications.
- For OAuth or third-party tokens, use a Backend for Frontend (BFF) pattern where tokens are stored server-side, and the browser only holds an HTTP-only session cookie, preventing token exposure to JavaScript.
- Refresh token rotation and reuse detection enhance security by invalidating stolen refresh tokens and forcing re-authentication.
- Device Bound Session Credentials (DBSC) bind sessions to hardware, preventing stolen cookies from being used long-term, though adoption is currently limited.
- For React applications, centralize token handling in an API wrapper to manage token refresh and prevent concurrent refresh requests from causing logout.
You shouldn't trust Trusted Publishing
2 months ago
- Trusted Publishing is an authentication scheme for machine-to-machine trust, not for human trust in package safety.
- It uses OIDC to link CI/CD machine identities to package indexes, issuing short-lived, scoped publishing credentials.
- PyPI avoids displaying Trusted Publishing status prominently to prevent misuse as a trust signal for package quality.
- Trusted Publishing reduces long-lived credentials but can still be compromised if CI/CD workflows are attacked.
- The scheme is optional and does not guarantee package safety; anyone can use it, including for malicious uploads.
- Attestations on PyPI are separate from Trusted Publishing and also do not imply end-user trust without independent verification.
Better Auth is joining Vercel
2 months ago
- Better Auth is joining Vercel, combining forces to advance auth solutions with a focus on open-source, framework-agnostic approaches and exploring agent security in AI-driven workflows.
- The founder built Better Auth after experiencing challenges with existing auth tools like NextAuth, leading to the creation of a framework-agnostic auth framework that gained community traction.
- Better Auth became a company after joining Y Combinator, raising capital, and later acquiring Auth.js/NextAuth.js to enhance its offerings and community reach.
- Future plans include advancing Better Auth's mission with Vercel's support, developing Agent Auth for secure agentic workflows, and continuing open-source contributions without monetization pressures.
AI Authentication and Authorization
2 months ago
- AI security relies on existing identity and authorization patterns from the API boom.
- Three AI use cases discussed: RAG, tool use (MCP/APIs), and agentic systems.
- RAG requires authorization to filter documents before they reach the LLM.
- Tool use involves controlling AI access to APIs and services via authentication methods like OAuth 2.1.
- Agentic systems need a chain of identity to track human authorization through workflows.
- Deterministic identity enforcement is crucial for probabilistic AI systems.
- FusionAuth examples illustrate implementation with fine-grained authorization and audit logging.

authentication

What DMARC Protects You From, and What It Does Not

Announcing License Key Authentication

What's the best way to do authentication in modern applications

You shouldn't trust Trusted Publishing

Better Auth is joining Vercel

AI Authentication and Authorization