Refactoring NestJS Auth: Adding Username & GitHub OAuth
Explore how to refactor a NestJS authentication project built with brkpt-auth by adding a username field and implementing GitHub OAuth integration.
Stock photo for illustration only, not from the actual event
- Introduce a unique username field alongside email for identification
- Create a LinkedAccount table to manage multiple OAuth provider connections
- Install GitHubOAuthDriver to support GitHub authentication
- Modify core adapters with zero edits to brkpt-auth internal files
Following the previous post that built a password and Google sign-in MVP using brkpt-auth, this recent update tackles two natural changes that emerge as a product grows: introducing a public username field and adding a second OAuth provider. These updates test how easily the existing architecture adapts to evolving requirements.
The application now requires a public, unique handle that users can share and search for, independent of their changing email addresses. While the credentials flow was initially set up using email for convenience, it is fundamentally designed around a username-and-password structure. However, collecting unverified emails paired with OAuth introduces potential security gaps if registration happens using a stranger's address, which can be mitigated using email verification features.
Adding a required and unique column like username to an existing database requires a careful backfill migration plan for legacy rows. In this particular implementation, the database was reset entirely to keep the primary focus firmly on adapter and schema modifications rather than writing migration scripts.
Stock photo for illustration only, not from the actual event
Regarding OAuth mapping, relying solely on email as an identifier creates flaws if a user changes their email and logs in through a different provider route, inadvertently spawning duplicate accounts. The standard engineering solution implemented here is a dedicated LinkedAccount table, allowing a single user record to safely associate with multiple independent provider identities.
With the account-linking table already established, introducing GitHub support becomes streamlined. Running brkpt auth add oauth --driver github installs the GithubOAuthDriver, which exchanges authorization codes for access tokens and queries GitHub's /user endpoint using a distinct request shape compared to Google.
"Two real requirements, three adapters, two DTOs, and one new table touched, zero files owned by brkpt-auth edited."
Brkpt
When evaluated against rolling out a custom authentication scheme using Passport—which typically demands numerous strategies, guards, and shared services—this approach confines the underlying business logic neatly inside adapters you already own, keeping boilerplate controllers and generated services entirely out of your way.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment