#auth

Tailscale can integrate with identity providers that support OpenID Connect (OIDC). The steps provided in this topic are required only for initial creation of a tailnet. After the signup process is completed, Tailscale will work like any other supported identity provider. For more information about OIDC, refer to Welcome to OpenID Connect.

Tailscale requires a properly configured WebFinger endpoint at .well-known/webfinger on the domain used for your email. Set this up according to your web server or application specifications.

Another cool thing about Tailscale is that they try to keep as little information about their users as possible, and so do not have their own login mechanism, instead leaving this task to common authentication providers like Google and Microsoft, or allowing the use of any identity provider compatible with OpenID Connect, which is the case for Authentik, and the topic of this post.

Pocket ID is a simple and easy-to-use OIDC provider that allows users to authenticate with their passkeys to your services.

Simple and opinionated OpenID Connect server designed for self-hosters

Better Auth is framework-agnostic authentication (and authorization) framework for TypeScript. It provides a comprehensive set of features out of the box and includes a plugin ecosystem that simplifies adding advanced functionalities. Whether you need 2FA, multi-tenant support, or other auth releated features. It lets you focus on building your actual application instead of reinventing the wheel.

Passwords are broken. Inspired by Justin Balthrop's article Passwords are Obsolete token-based one-time password (OTPW) authentication is faster to deploy, better for your users, and more secure.

Passwords are broken. Inspired by Justin Balthrop's article Passwords are Obsolete token-based one-time password (OTPW) authentication is faster to deploy, better for your users, and more secure.

This will post a new tweet on behalf of the user, telling everyone they joined your website!

This will post a new tweet on behalf of the user, telling everyone they joined your website!

When developers build software, it routinely includes modules that run on a Web server, other modules that run in the browser, and others that run as native mobile apps. Both developers and the people who use their software typically think of all these modules as part of a single app. Google’s OAuth2 implementation supports this view of the world

We already showed you how to build a Beautiful REST+JSON API, but how do you secure your API? At Stormpath we spent 18 months researching best practices, implementing them in the Stormpath API, and figuring out what works. Here’s our playbook on how to secure a REST API.

A simple Google Authenticator app written in HTML

So I started wondering - what if we just created a real user for every person who visited the site? Django already has support for creating users with unusable passwords - so if we just create a user with an unusable password every time a new person comes along, log them in, and then at some future point (presumably once they've fallen in love with your site) they can set themselves up with a real username and password. And as a bonus, all that data that they created while messing about with the site sticks around, and carries over into their 'real' user.

"This snippet for Piston allows you to offer a choice of authentication methods to clients."

"A clean, simple, and unobtrusive ruby authentication solution."

"Over the weekend we quietly rolled out support for the oauth protocol."

"What if you could say, "by default, trust whatever my buddy Pete trusts"? Or, "trust the consensus of my set of friends; only ask me if there's disagreement"? Or more prosaically, "trust what my local IT department says"."