당신의 앱에 대한 자체 인증을 구축해야 합니까?
나는 많은 개발자들이 "내 앱에 대한 나만의 인증을 구축해야 하는가?"라는 질문을 하는 것을 보았다. 답이 간단히 "예" 또는 "아니오"로 나올 수 없기 때문에, 이를 도와줄 수 있도록 실행을 분해하고 장단점을 보여주는 기사를 쓰고 싶었다.
나는 많은 개발자들이 "내 앱에 대한 나만의 인증을 구축해야 하는가?"라는 질문을 하는 것을 보았다. 답이 간단히 "예" 또는 "아니오"로 나올 수 없기 때문에, 이를 도와줄 수 있도록 실행을 분해하고 장단점을 보여주는 기사를 쓰고 싶었다.
나는 많은 개발자들이 "내 앱에 대한 나만의 인증을 구축해야 하는가?"라는 질문을 하는 것을 보았다. 답이 간단히 "예" 또는 "아니오"로 나올 수 없기 때문에, 이를 도와줄 수 있도록 실행을 분해하고 장단점을 보여주는 기사를 쓰고 싶었다.
TL;DR 진정으로 완전한 제어를 원하거나 아직 소프트웨어 개발을 배우고 있는 경우가 아니라면, 반드시 필요에 맞는 기존 해결 방법을 찾아야 합니다.
개발자로서, 나는 내 커리어 동안 많은 어플리케이션을 구축했다. 프로그래밍 언어에 관계없이, 나는 항상 구축해야 하는 공통 기반을 가지고 있다: 사용자 인증.
20년 전으로 돌아가면 모든 것이 간단하기 때문에 이는 무시할 만한 부분이었습니다.:
그게 다였습니다. 그런 다음 나는 "진짜 평가"에 집중할 수 있었습니다. MD5에 대해 듣지 못했냐구요? 소프트웨어 개발의 "좋은 시절"을 놓쳤답니다. 요즘 개발자들은 로그인/업을 구축할 때 더 많은 도전에 직면하고 있습니다.
비상을 울리는 것처럼 들릴 수 있지만, 예를 들어 자세히 설명해 보겠습니다.
당신이 API 서비스와 웹 프론트엔드 앱을 가진 온라인 서점을 구축하려고 한다고 가정해 봅시다.
먼저, "auth"의 범위를 정의해야 합니다. Auth는 인증과 권한을 설명할 수 있으며, 그들은 전적으로 다른 정의와 사용 사례를 가지고 있습니다:
나는 이 개념들에 대해 자세히 논의하기 위해 CIAM 101: 인증, 신원, SSO라는 기사를 썼습니다.
우리의 예에서 "인증", 즉 사용자 로그인 부터 시작해봅시다. 사용자 이름과 암호 방법 뿐만 아니라, 여기에는 사용자 전환와 보안을 더 잘 하기 위해 사람들이 채택하려는 트렌드가 있는 방법들이 있습니다:
방법의 선택은 사업 결정에 따라 다르며, 우리는 기술 노력에 대해 살펴볼 수 있습니다:
[email protected]으로 로그인하면, 이 이메일 주소를 서점의 사용자 foo에 연결할 수 있습니다. 이 과정은 통합 신원 체계를 구축하는 데 도움이 되며 사용자가 미래에 소셜 신원을 수정하거나 연결 해제할 수 있게 합니다.인증 방법을 결정한 후, 최종 사용자를 위한 매끈하고 우아한 로그인 경험이 다음 타겟이다. 여기서의 변환은 기본적이지만 사업에 있어서 중요하다 왜냐하면, 그것은 유지되는 고객 데이터를 남기는 자연스러운 방법이기 때문이다.
내가 Airbnb에서 일할 때, 여러 플랫폼에 대해 로그인 경험을 최적화하기 위해 전담 팀이 있었다. 그들은 가장 높은 전환율을 가진 조합을 결정하기 위해 수많은 A/B 테스트를 진행했다.
사업이 시작될 때 이러한 것을 하는 것은 실질적이지 않다. 하지만 우리는 여전히 모든 조각이 올바르도록 최선을 다해야 한다. 서점을 어떤 플랫폼에서 실행하고 싶으십니까? 여러분은 모바일, 웹, 또는 둘 다로 시작할 수 있습니다. 정확한 디자인은 여러분이 선택한 인증 방법에 따라 달라집니다:
그것을 더 잘 만들기 위해 생각해 볼 것들이 더 있습니다:
만약 네이티브 개발을 선택한다면, 추가 플랫폼 하나당 작업량이 거의 두 배가 될 것입니다.
보안은 숨어 있는 빙산이 될 수 있습니다. OpenID Connect나 OAuth 2.0에 익숙하다면 좋겠습니다, 왜냐하면 이들은 널리 사용되며 시험을 거쳤기 때문입니다. OpenID Connect는 상대적으로 새로움이지만, "사용자 인증"을 위해 설계되었으므로 온라인 서점에 적합합니다.
표준의 세부 사항을 깊게 파고들지 않고도, 고려해야 할 일들이 몇 가지 더 있습니다:
마지막으로, 좋은 로그인 경험을 사용자에게 제공할 수 있습니다.
서점으로서, 고객과 판매자를 위한 자원을 구별해야 합니다. 예를 들어, 고객은 모든 책을 둘러볼 수 있고, 판매자는 판매 중인 책을 관리할 수 있습니다. 비즈니스가 성장하면서, 여러분은 역할 기반 접근 제어(RBAC)나 속성 기반 접근 제어(ABAC)와 같은 더 유연한 모델을 사용해야 할 수 있습니다.
또한 나는 CIAM 102: 인증 및 역할 기반 접근 제어라는 기사를 썼어 기본적인 인증 개념과 RBAC 모델을 보여주기 위해.
auth는 "모든 것 또는 아무 것도 아닌" 문제가 아니라는 것을 볼 수 있습니다, 재정적 요소와 여러분이나 여러분의 팀이 이러한 영역에서 갖는 다른 기술 전문 지식을 포함하기 때문입니다. 현 상황을 더 잘 이해하기 위해 그것을 더 작은 부분으로 분해하는 것이 중요합니다.
누구에게 어떤 결정을 내릴 것인가를 생각하면, 나는 다음 질문들을 내 자신에게 묻습니다:
질문들이 머릿속에 있으면, 나는 두 가지 사실을 발견하였습니다:
그래서 나는 인증을 위한 전용 프로젝트(Logto)를 시작하기로 결정했고, 첫날부터 오픈 소스 커뮤니티를 받아들였습니다.
이 글이 도움이 되길 바랍니다.