나보다 똑똑한 사람이 왜 Postgres users 테이블을 서드파티 제공자에게 넘겨야 하는지 설명해줬으면 함
Hetzner VM에 있는 테이블을 직접 유지하는 게 뭐가 그렇게 어려운지 모르겠음. 결제도 아니고 그냥 몇 개 필드가 있는 데이터일 뿐임
몇 개 필드일 때는 그렇지만, 곧 그렇게 단순하지 않게 됨 SSO, SAML, SCIM, OIDC, OAuth, 2단계 인증, 비밀번호 없는 인증, 검증 토큰 등이 붙고, 각 기능마다 널리 쓰이는 시스템과의 변형 통합까지 요구됨. 우리 회사에서는 한동안 지원 엔지니어 시간의 절반이 직접 만든 인증 시스템의 온갖 SSO 문제 처리에 들어갔음
나도 비슷하게 이해가 안 됨. Supabase 같은 게 왜 존재하는지도 늘 의문이었고, 프론트엔드 개발 세계가 기본적으로 단순하고 안전하게 만들 수 있는 방식에서 얼마나 떨어져 있는지 보여주는 듯함
커리어를 아키텍트로 올리고 싶지 않나? 박스 하나 그리고 User Management라고 이름 붙인 뒤 Clerk 같은 SaaS를 붙이면 관리되는 것으로 가정할 수 있음
그러면 “이건 내가 구현해도 가치가 없다”고 느끼는 요구사항은 전부 그 마법의 블랙박스에 밀어 넣을 수 있음
사람들은 인증을 망쳐서 해킹당하는 것을 매우 두려워함. 그래서 그 책임을 서드파티에 넘기고 신경 쓰지 않으려는 경향이 있음
나도 똑같이 혼란스러움. 대략 보기엔 요구사항이 넓지 않은 범위에서는 데이터베이스를 직접 운영하고 Django 같은 것으로 인증을 관리하는 편이 더 쉬움
엔터프라이즈 규모에서는 달라질 수도 있겠음
Better Auth의 Bereket임. 나도 바로 이 문제를 해결하려고 Better Auth를 시작했고, 이후 회사가 됐음
다른 사람들이 같은 가치를 얻는 걸 보는 게 늘 기쁨. 아직 할 일이 많아서, 무엇을 개선하면 좋을지 알고 싶음
Python 백엔드 지원 계획이 있는지 궁금함. 아니면 우리가 쓸 수 있는 방법이 있는지 알고 싶음
브라우저에서 인증이 복잡한 이유가 브라우저가 충분히 해주지 않기 때문이라고 보나?
“복잡한 시스템을 만들며 배우는 어려운 교훈은, 그 신뢰성이 핵심 부품들의 신뢰성 중 최솟값이라는 것이다”보다 더 나쁨
실제로는 핵심 경로에 있는 모든 구성요소의 가용성 곱이 전체 가용성이 됨. 소프트웨어, 인증 계층, 클라우드 제공자가 각각 99% 가용성이고 셋 중 하나만 죽어도 서비스가 내려간다면 최종 가용성은 97%뿐임. 그런 구성요소가 11개면 가용성에서 “나인”이 하나도 남지 않음. 그래서 구성요소를 줄이고 신뢰성 높은 해법을 택하는 게 중요하며, 이 팀이 그 길을 택해서 좋음
지난번 큰 Cloudflare 장애 때 이걸 어렵게 배움. 나는 Cloudflare를 쓰지 않았는데도, JWT 검증에 쓰는 Auth0 공개 키가 Cloudflare 뒤에서 제공되고 있어서 인증 체인이 통째로 깨졌고 앱이 몇 시간 동안 먹통이 됐음
최근 비슷한 과정을 겪음. Stack Auth로 시작했지만 극단적으로 빡센 속도 제한과 나쁜 성능 때문에 프로덕션에서 쓸 수 없었고, 속도 제한에 걸리지 않아도 느렸음
이후 WorkOS AuthKit으로 옮겼고 훨씬 잘 동작하며 유용한 엔터프라이즈 기능도 지원함. 그래도 새 프로젝트라면 Better Auth 쪽에 끌림. 외부 인증 제공자의 상태와 내 사용자 상태를 동기화하는 건 버그의 온상이고, 인증 제공자에 가능한 한 상태를 적게 두는 게 도움이 되지만 그래도 일부는 남음. JWT 접근 토큰을 몇 분마다 갱신하는 것도 또 다른 버그의 온상이며, 인증을 직접 제어한다면 솔직히 그럴 필요가 없음. WorkOS는 완전한 API가 아니고, 과금 계정당 제품 하나와 고정된 환경 수(staging, production, 지원에 요청하면 하나 더)라는 가정 위에 만들어져 있음. 리다이렉트 URL 같은 것도 대시보드에서 허용 목록에 넣어야 하고, 에이전트가 쉽게 처리할 방법은 없어 보임. 인증 외주화는 별로 말이 안 된다고 봄. 상태를 여러 서비스에 덜 쪼갤수록 문제가 줄어듦. 결제처럼 불가피하거나 성능 때문에 특수 데이터베이스가 필요한 경우도 있지만, 좋은 라이브러리가 있다면 인증에는 정말 그럴 이유가 없음. 서비스를 쓰면 더 빨리 시작할 수 있다는 주장도 있지만, 내가 인증 서비스에서 겪은 문제는 고규모와 관련이 없었고 대부분 출시 전부터 터졌음
Clerk를 쓰고 있는데 꽤 불만족스러움. 제대로 된 RBAC가 없음
역할이 사용자 자체가 아니라 조직에 묶여 있어서 전역 관리자 같은 개념을 둘 수 없고, 임의 키-값 쌍을 metadata에 저장하는 식으로 우회해야 함. 지난 몇 주·몇 달 사이에도 다운타임이 여러 번 있었고, 그때마다 앱 전체가 실패했음. 앞으로 다시 쓸지는 두 번 생각할 듯함
초기에 Lucia를 선택해서 정말 다행이라고 느낌. 라이브러리는 사실상 종료하고, 인증을 직접 관리하고 호스팅하는 방법을 문서와 작은 유틸리티로 대체했음
인증은 늘 직접 관리할 수 없는 크고 무서운 일처럼 제시되지만, 보안과 기본적인 솔팅이 어떻게 동작하는지 일주일 정도 배워보니 전체 동작 방식에 훨씬 자신감이 생겼음
Clerk와 Better Auth 비교는 거의 불공정하다고도 할 수 있음. 하나는 서비스고 하나는 라이브러리라서 사과와 오렌지 비교임
스택에 통합되는 모든 서드파티 서비스는 책임 부담이 되고, 라이브러리도 그렇지만 정도가 덜함. 이제 더 많은 서비스가 라이브러리로 대체될 때가 됐고, Better Auth가 그 방식을 잘 보여줌. 프론트엔드, 백엔드, 데이터베이스에 통합되는 라이브러리라서 좋음
Tom의 글은 항상 읽을 만함 Auth0와 passportjs를 기억하는 사람이 있나? 인증 서비스의 변화는 끝이 없지만, 표준도 계속 변하니 어쩔 수 없는 듯함
OAuth 2.x와 OIDC는 크게 변하지 않았음. 나는 아직도 Firebase와 함께 Passport.js를 씀
Hacker News 의견들
나보다 똑똑한 사람이 왜 Postgres users 테이블을 서드파티 제공자에게 넘겨야 하는지 설명해줬으면 함
Hetzner VM에 있는 테이블을 직접 유지하는 게 뭐가 그렇게 어려운지 모르겠음. 결제도 아니고 그냥 몇 개 필드가 있는 데이터일 뿐임
SSO, SAML, SCIM, OIDC, OAuth, 2단계 인증, 비밀번호 없는 인증, 검증 토큰 등이 붙고, 각 기능마다 널리 쓰이는 시스템과의 변형 통합까지 요구됨. 우리 회사에서는 한동안 지원 엔지니어 시간의 절반이 직접 만든 인증 시스템의 온갖 SSO 문제 처리에 들어갔음
그러면 “이건 내가 구현해도 가치가 없다”고 느끼는 요구사항은 전부 그 마법의 블랙박스에 밀어 넣을 수 있음
엔터프라이즈 규모에서는 달라질 수도 있겠음
Better Auth의 Bereket임. 나도 바로 이 문제를 해결하려고 Better Auth를 시작했고, 이후 회사가 됐음
다른 사람들이 같은 가치를 얻는 걸 보는 게 늘 기쁨. 아직 할 일이 많아서, 무엇을 개선하면 좋을지 알고 싶음
“복잡한 시스템을 만들며 배우는 어려운 교훈은, 그 신뢰성이 핵심 부품들의 신뢰성 중 최솟값이라는 것이다”보다 더 나쁨
실제로는 핵심 경로에 있는 모든 구성요소의 가용성 곱이 전체 가용성이 됨. 소프트웨어, 인증 계층, 클라우드 제공자가 각각 99% 가용성이고 셋 중 하나만 죽어도 서비스가 내려간다면 최종 가용성은 97%뿐임. 그런 구성요소가 11개면 가용성에서 “나인”이 하나도 남지 않음. 그래서 구성요소를 줄이고 신뢰성 높은 해법을 택하는 게 중요하며, 이 팀이 그 길을 택해서 좋음
예전에 나온 Supabase 마이그레이션 글(https://blog.val.town/blog/migrating-from-supabase)도 재미있게 읽었음
장기적인 엔지니어링 결정에 대해 솔직하고 좋은 글이 부족한데, 계속 블로그를 써줬으면 함
최근 비슷한 과정을 겪음. Stack Auth로 시작했지만 극단적으로 빡센 속도 제한과 나쁜 성능 때문에 프로덕션에서 쓸 수 없었고, 속도 제한에 걸리지 않아도 느렸음
이후 WorkOS AuthKit으로 옮겼고 훨씬 잘 동작하며 유용한 엔터프라이즈 기능도 지원함. 그래도 새 프로젝트라면 Better Auth 쪽에 끌림. 외부 인증 제공자의 상태와 내 사용자 상태를 동기화하는 건 버그의 온상이고, 인증 제공자에 가능한 한 상태를 적게 두는 게 도움이 되지만 그래도 일부는 남음. JWT 접근 토큰을 몇 분마다 갱신하는 것도 또 다른 버그의 온상이며, 인증을 직접 제어한다면 솔직히 그럴 필요가 없음. WorkOS는 완전한 API가 아니고, 과금 계정당 제품 하나와 고정된 환경 수(staging, production, 지원에 요청하면 하나 더)라는 가정 위에 만들어져 있음. 리다이렉트 URL 같은 것도 대시보드에서 허용 목록에 넣어야 하고, 에이전트가 쉽게 처리할 방법은 없어 보임. 인증 외주화는 별로 말이 안 된다고 봄. 상태를 여러 서비스에 덜 쪼갤수록 문제가 줄어듦. 결제처럼 불가피하거나 성능 때문에 특수 데이터베이스가 필요한 경우도 있지만, 좋은 라이브러리가 있다면 인증에는 정말 그럴 이유가 없음. 서비스를 쓰면 더 빨리 시작할 수 있다는 주장도 있지만, 내가 인증 서비스에서 겪은 문제는 고규모와 관련이 없었고 대부분 출시 전부터 터졌음
Clerk를 쓰고 있는데 꽤 불만족스러움. 제대로 된 RBAC가 없음
역할이 사용자 자체가 아니라 조직에 묶여 있어서 전역 관리자 같은 개념을 둘 수 없고, 임의 키-값 쌍을 metadata에 저장하는 식으로 우회해야 함. 지난 몇 주·몇 달 사이에도 다운타임이 여러 번 있었고, 그때마다 앱 전체가 실패했음. 앞으로 다시 쓸지는 두 번 생각할 듯함
초기에 Lucia를 선택해서 정말 다행이라고 느낌. 라이브러리는 사실상 종료하고, 인증을 직접 관리하고 호스팅하는 방법을 문서와 작은 유틸리티로 대체했음
인증은 늘 직접 관리할 수 없는 크고 무서운 일처럼 제시되지만, 보안과 기본적인 솔팅이 어떻게 동작하는지 일주일 정도 배워보니 전체 동작 방식에 훨씬 자신감이 생겼음
라이브러리를 폐기하고 인증을 처음부터 구현하는 학습 자료로 바꿨던 때가 기억남. 훌륭한 결정이었고, 작성자를 매우 존중함
Clerk와 Better Auth 비교는 거의 불공정하다고도 할 수 있음. 하나는 서비스고 하나는 라이브러리라서 사과와 오렌지 비교임
스택에 통합되는 모든 서드파티 서비스는 책임 부담이 되고, 라이브러리도 그렇지만 정도가 덜함. 이제 더 많은 서비스가 라이브러리로 대체될 때가 됐고, Better Auth가 그 방식을 잘 보여줌. 프론트엔드, 백엔드, 데이터베이스에 통합되는 라이브러리라서 좋음
Tom의 글은 항상 읽을 만함
Auth0와 passportjs를 기억하는 사람이 있나? 인증 서비스의 변화는 끝이 없지만, 표준도 계속 변하니 어쩔 수 없는 듯함