6P by GN⁺ 4일전 | ★ favorite | 댓글 4개
  • Auth.js(이전 명칭: NextAuth.js) 가 이제 Better Auth 팀에 의해 유지 및 관리됨
  • Auth.js는 JavaScript 생태계에서 가장 널리 사용되는 오픈 소스 인증 라이브러리로 많은 유명 웹사이트에서 활용됨
  • 이전에는 직접 인증과 세션 관리를 구현하는 데 어려움이 있었으며, 모든 현장에서 동일한 기본 요소를 반복 개발하는 불편함이 존재
  • Better Auth 팀이 Auth.js의 한계를 인식하고 미래 비전을 공유함에 따라, 두 프로젝트가 결합해 생태계를 더욱 발전시킬 계획
  • 기존 사용자들은 보안 패치 등 유지보수를 계속 받을 수 있으며, 신규 프로젝트의 경우 Better Auth 사용을 권장함

소개 및 발표

  • Auth.js(이전에는 NextAuth.js로 알려짐) 가 이제 Better Auth 팀에 의해 공식적으로 유지 및 관리됨
  • Auth.js는 JavaScript 생태계에서 가장 잘 알려진 오픈 소스 인증 라이브러리 중 하나로, 이미 많은 서비스(ChatGPT, Google Labs, Cal.com 등)에서 사용되는 중임

기존 Auth.js의 역할과 한계

  • Better Auth로 통합되기 전, Auth.js는 개발자들이 OAuth 통합이나 세션 관리에 장시간 투자하지 않고도 인증 기능을 소유할 수 있게 해줌
  • 하지만 웹 애플리케이션이 복잡해지고 인증 요구가 다변화됨에 따라, 반복적인 기본 기능 개발이나 확장성 부족 등 한계가 두드러졌음
  • 기존 팀도 이러한 점을 인식하고 있었지만, 여러 가지 이유로 근본적인 개선까지 실행하지 못함

Better Auth와의 합병 배경

  • Better Auth의 목표는 다양한 서비스에서 인증 소유권을 강화하는 것이었으며, Auth.js 팀과의 비전 역시 유사했음
  • 내부 논의를 거치면서 두 프로젝트가 하나가 되는 것이 최선임을 깨달음
  • 현재 Auth.js가 수많은 애플리케이션, 기업, 개발자들에게 중요하다는 점을 인식하고, 지속적으로 보안 패치와 긴급 이슈 대응을 약속함

권장 사항 및 생태계 발전 전략

  • 기존에 Auth.js(NextAuth.js)를 사용하는 프로젝트는 계속해서 문제없이 사용할 수 있음
  • 신규 프로젝트의 경우, 특정 기능(대표적으로 데이터베이스 없이 stateless session 관리)이 필요하지 않다면 Better Auth를 사용하는 것을 권장함
  • Better Auth의 로드맵에는 이 기능들도 추가 예정임. 중복 개발 대신 생태계가 하나로 통합되어 더 발전적인 방향을 모색함

마이그레이션 및 커뮤니티에 대한 감사

  • 마이그레이션을 고려하는 팀에게는 가이드를 제공하며, 더 많은 문서와 자료를 곧 추가할 예정임
  • 여태까지 Auth.js를 발전시킨 커뮤니티와 주요 기여자들(특히 Balázs, Thang Vu, Nico Domino, Lluis Agusti, Falco Winkler)에게 깊은 감사를 전함
  • Better Auth의 시작점이 Auth.js였으며, 두 프로젝트의 결합으로 인증 생태계가 더 멀리 나아갈 수 있음을 강조함
  • 기본 목표는 변함없이, "인증 소유권은 개발자 자신에게 있음"을 지향함

이렇게 불안정한건 쓰는거보다 그냥 clerk 같은거 사용하고 사용자 많아지면 그때 진지하게 인증문제 고민하는게 좋겠네요

auth.js로 얼마전에 뭐하나 만들어봤는데 그새 뭐가또 바뀌네요. 웹쪽은 매우 난감 피곤하군요. 그리고 제가 문서와 예제가 틀린게 있어서 PR요청도 해봤는데 별문제 없단 식으로 닫아버려서 많이 황당했는데. 내부적으로 팀이 잘안돌아가는 상태였던거 같음.

Hacker News 의견
  • Better Auth가 500만 달러 투자를 유치했음, 완전 무료 프로젝트가 상업적 벤처에 흡수되는 현상이 아쉽게 느껴짐

    • Auth.js와 NextAuth.js의 상황이 별로 건강하지 않았음, NextAuth.js v5 개발이 2023년 5월부터 시작됐지만 계속 베타 상태임, 2023년 8월에 Auth.js로 이름이 바뀌었고 10월에 v5.0.0-beta.0이 나왔음, 메인 컨트리뷰터인 Balázs Orbán이 2025년 1월에 팀을 떠남, 결국 아직도 안정화 버전 없이 베타에 머무르고 있음
      변천사, 토론, 이름 변경 기록, 베타 출시, 커밋 내역, X(트위터) 발표 참고
    • 이런 우려는 이해하지만, Auth.js는 오히려 "진짜 무료"였다고 보지 않음, 많은 기업(Clerk도 문서 사이트에 광고를 실을 정도로)들의 지원을 받고 있었음, Better Auth는 처음엔 상업적 목적 없이 오픈소스 프로젝트로 시작했지만 더 많은 회사들이 손쉽게 인증 시스템을 소유할 수 있게 하고 싶어서 상업적 확장이 자연스럽게 이루어졌음, Auth.js를 맡게 된 이유도 팀이 프로젝트에서 손을 떼기로 해서 방치되는 걸 막기 위함임, Lucia처럼 오픈소스 인증이 신뢰를 잃는 사례가 이미 있었고, 실제로 방치돼서 신뢰가 무너지는 상황을 막고 싶었음
    • Auth.js는 완전히 무료이긴 하지만 사실상 방치된 상태임
    • 나는 FusionAuth에서 일하며 NextAuth에 후원을 한 경험이 있음, 사람들이 생계를 유지해야 하고 NextAuth도 후원사들의 상업적 지원을 받은 프로젝트임, 사실 후원에서 나온 돈이 얼마나 많았는지 등은 정확히 모르겠지만, Clerk와 Vercel이 프로젝트에 영향을 준 것처럼 관련 의견들을 참고하면 좋겠음, 오픈소스 비즈니스 모델의 어려움에 대해 개인 블로그에 더 상세히 적은 글이 있으니 참고 바람
    • 이번 경우엔, 최소한 모금된 자금이 오픈소스 프로젝트를 기반으로 한 미래의 SaaS 인증 솔루션 개발을 위한 것 같음
  • ChatGPT, Google Labs, Cal.com 등에서 Auth.js가 실제로 활용되고 있다는 얘기를 들음, 그런데 OpenAI가 Auth0에서 인증 시스템을 옮긴 걸 못 봤는데 혹시 무슨 일이 있었는지 궁금함

    • 특별히 아는 이야기는 없지만, 내 경험상 Auth0로 전환을 시도했던 적이 있는데 별로였음, 살짝만 표준에서 벗어나도 지원이 매우 떨어지고, 정상 작동해도 썩 좋지 못함, 그래도 써드파티 SaaS로 인증을 외주해야 한다면 Auth0가 그나마 나은 선택지일 수도 있겠음
    • OpenAI의 실제 사례를 Ory 공식 케이스 스터디에서 일부 짐작해 볼 수 있음
    • AWS Cognito와 Auth0를 두고 고민하는 중임, 실제로 Cognito와 Auth0 중 어느 쪽이 더 나은 체감인지 다양한 사람들의 경험담이 듣고 싶음
    • OpenAI는 SSO/SAML을 WorkOS로 이전하고, 일반 소비자 인증은 오픈소스를 포크해서 쓴 것으로 보임
    • Ory 역시 자신들이 OpenAI에서 쓰인다고 주장하니, 아마 OpenAI가 Ory 서비스와 Better Auth 등을 조합해서 솔루션을 구축한 것 같음
  • 이 프레임워크 때문에 인증 처리를 전혀 신경 쓰지 않아도 될 만큼 쉬워졌음, 설정도 간단하고 프레임워크마다 사용법도 일관적임, 앞으로도 이런 장점이 계속될 것 같아 다행임

  • 누군가 Better Auth가 ‘auth.js보다 나은가?’라고 물었을 때, 순간적으로 "auth.js보다 낫지"라고 생각했는데, 결국 그렇게 된 셈임

  • Go 언어에도 이렇게 간편한 인증 솔루션이 있으면 좋겠음

    • 내가 직접 Go, JS, Rust(서버사이드 WASM 활용)까지 지원하는 솔루션을 만들고 있음, 앞으로 Python 등도 지원 예정이고, BetterAuth/OpenAuth 수준의 완성도나 기능은 없겠지만, 프로젝트에서 인증이 필요할 때 개발 경험(DX)은 매우 만족스러움
      decent-auth 깃허브
    • 나도 완전 공감함, golang을 위한 인증 솔루션이 없진 않은데(FusionAuth처럼), Rails의 devise, Django의 사용자 모델처럼 앱에 직접 녹아드는 프레임워크 수준의 쉬운 라이브러리를 원하는 것 같음, 해당 주제에 대한 reddit 스레드에 여러 대안도 소개되어 있으니 참고해 볼 만함
    • authelia/authelia 깃허브도 시도해볼 만함
    • ory/kratos 깃허브 역시 가능성 있음
  • 두 제품 모두 사용해 봤고 개인적으로 만족했음, 두 프로젝트가 협력하게 되어 좋음

    • 실상은 Better Auth가 Auth.js를 유지하는 척하면서 사람들을 Better Auth로 유도하려는 것일 뿐임
  • Clerk을 써보고 있는데 괜찮아 보임, 뭐든 소문이 있지만 나는 일단 개발에 집중하고 싶음

    • Clerk은 아직 시도해보지 않았지만, 돈을 쓰는 것이 실제로 개발을 쉽게 해준다면 특정 프로젝트엔 잘 맞을 것 같음, 참고로 Better Auth는 내 bare-bones 리포에도 1시간도 안 걸려서 세팅이 끝났음
  • 개발자 입장에서 단순함을 극대화시켜줘서 Better Auth가 그냥 더 낫다는 느낌임

  • 이 소식이 아쉽게 느껴짐, 사실상 Auth.js의 추가 개발이 중단되는 것 같음, 나는 Auth.js의 단순한 함수 구현만으로 내 GraphQL API 뒷단에서 완벽하게 활용할 수 있어서 좋았지만, Better Auth는 데이터 타입이 플러그인마다 달라서 타입스크립트 any처럼 너무 일반적임, 또 데이터베이스 스키마 설계나 마이그레이션 수행 책임까지 플러그인 개발자에게 위임됨, 인증 라이브러리로선 너무 과하다고 생각하며 이 구조가 마음에 들지 않음, 어댑터를 따로 만들 수도 있지만 그 인터페이스조차 너무 일반 SQL-like 임의 쿼리 실행기를 구현해야 해서 스키마에 대한 직접적 통제권이 사라짐, 마이그레이션도 그냥 코드 문자열로 받고 eval 하는 구조라 보안에 대한 통제도 쉽지 않음
    예전부터 Better Auth가 기술적 참신함보단 개발자가 독학했다거나 젊다는 점에 주목받는 분위기라 편견을 가지지 않으려 했지만, 이런 우려마저 완전히 틀린 건 아닌 듯함, 그나마 Auth.js가 방치된 현상보다는 낫지만, JS 생태계의 오픈소스 인증 라이브러리 상태가 그만큼 아쉬움
    adapter 구현 예시, 테크크런치에 소개된 개발자 기사

      1. Auth.js를 완전히 종료하는 일은 기존 사용자들이 문제없이 Better Auth로 옮길 수 있다고 확신할 때만 할 것임(즉, 아직은 요원함), 사실상 모두가 강제로 옮겨가야 하는 상황은 오지 않을 가능성이 높음
      2. 플러그인을 통한 추가 기능은 NextAuth엔 없는 것들임, 핵심 라이브러리만 써도 NextAuth의 거의 대부분 기능을 제공하고, 대부분의 플러그인을 우리가 직접 제공함, 원하는 경우 직접 플러그인을 작성하거나 복사/수정, 혹은 우리가 제공하는 플러그인만 사용할 수 있음, DB 처리는 알아서 해주니 직접 로직을 짤 필요 없이 인증 시스템을 소유할 수 있음
      3. Auth.js는 이미 한참 전부터 비활성 상태였음, 급격한 종료가 오픈소스 인증 생태계 신뢰에 치명적이라 이를 방지하기 위해 Better Auth로 가져온 것임, Lucia Auth 때도 경험했던 신뢰 상실 문제를 의식함
  • Better Auth 발표 이후 3시간 만에 Vercel 관련 공지를 깃허브 커밋에서 제거했음