당신의 앱에 대한 자체 인증을 구축해야 합니까?

배경#

나는 많은 개발자들이 "내 앱에 대한 나만의 인증을 구축해야 하는가?"라는 질문을 하는 것을 보았다. 답이 간단히 "예" 또는 "아니오"로 나올 수 없기 때문에, 이를 도와줄 수 있도록 실행을 분해하고 장단점을 보여주는 기사를 쓰고 싶었다.

TL;DR 진정으로 완전한 제어를 원하거나 아직 소프트웨어 개발을 배우고 있는 경우가 아니라면, 반드시 필요에 맞는 기존 해결 방법을 찾아야 합니다.

소개#

개발자로서, 나는 내 커리어 동안 많은 어플리케이션을 구축했다. 프로그래밍 언어에 관계없이, 나는 항상 구축해야 하는 공통 기반을 가지고 있다: 사용자 인증.

20년 전으로 돌아가면 모든 것이 간단하기 때문에 이는 무시할 만한 부분이었습니다.:

• 사용자 이름과 암호를 사용한 등록 및 로그인 시스템 구현.
• 사용자 세션을 유지하는 메커니즘을 만듭니다.
• 보안에 대해서는? MD5가 대답입니다.

그게 다였습니다. 그런 다음 나는 "진짜 평가"에 집중할 수 있었습니다. MD5에 대해 듣지 못했냐구요? 소프트웨어 개발의 "좋은 시절"을 놓쳤답니다. 요즘 개발자들은 로그인/업을 구축할 때 더 많은 도전에 직면하고 있습니다.

비상을 울리는 것처럼 들릴 수 있지만, 예를 들어 자세히 설명해 보겠습니다.

예제: 온라인 서점#

당신이 API 서비스와 웹 프론트엔드 앱을 가진 온라인 서점을 구축하려고 한다고 가정해 봅시다.

먼저, "auth"의 범위를 정의해야 합니다. Auth는 인증과 권한을 설명할 수 있으며, 그들은 전적으로 다른 정의와 사용 사례를 가지고 있습니다:

나는 이 개념들에 대해 자세히 논의하기 위해 CIAM 101: 인증, 신원, SSO라는 기사를 썼습니다.

인증 방법 선택#

우리의 예에서 "인증", 즉 사용자 로그인 부터 시작해봅시다. 사용자 이름과 암호 방법 뿐만 아니라, 여기에는 사용자 전환와 보안을 더 잘 하기 위해 사람들이 채택하려는 트렌드가 있는 방법들이 있습니다:

• Passwordless, 즉 동적 검증 코드 (이메일이나 sms를 통해)
• 소셜 로그인 (Google, Facebook 등)

방법의 선택은 사업 결정에 따라 다르며, 우리는 기술 노력에 대해 살펴볼 수 있습니다:

• Passwordless의 경우, 여러분은 이메일이나 sms를 통해 인증 코드를 보내는 제공업체를 찾아야 하며; 그런 다음 여러분의 API 서비스와 통합해야 합니다 (새로운 API가 필요할 수 있습니다).
• 소셜 로그인의 경우, 사용하고자 하는 소셜 아이덴티티 제공업체의 통합 지침을 따라야 합니다. 또한, 서점의 사용자 ID와 아이덴티티 제공업체의 ID 사이에 매핑을 생성해야 합니다.
  • 예를 들어, 사용자가 Gmail 계정 [email protected]으로 로그인하면, 이 이메일 주소를 서점의 사용자 foo에 연결할 수 있습니다. 이 과정은 통합 신원 체계를 구축하는 데 도움이 되며 사용자가 미래에 소셜 신원을 수정하거나 연결 해제할 수 있게 합니다.

로그인 경험 설계 및 구현#

인증 방법을 결정한 후, 최종 사용자를 위한 매끈하고 우아한 로그인 경험이 다음 타겟이다. 여기서의 변환은 기본적이지만 사업에 있어서 중요하다 왜냐하면, 그것은 유지되는 고객 데이터를 남기는 자연스러운 방법이기 때문이다.

내가 Airbnb에서 일할 때, 여러 플랫폼에 대해 로그인 경험을 최적화하기 위해 전담 팀이 있었다. 그들은 가장 높은 전환율을 가진 조합을 결정하기 위해 수많은 A/B 테스트를 진행했다.

사업이 시작될 때 이러한 것을 하는 것은 실질적이지 않다. 하지만 우리는 여전히 모든 조각이 올바르도록 최선을 다해야 한다. 서점을 어떤 플랫폼에서 실행하고 싶으십니까? 여러분은 모바일, 웹, 또는 둘 다로 시작할 수 있습니다. 정확한 디자인은 여러분이 선택한 인증 방법에 따라 달라집니다:

• 사용자 이름과 비밀번호: 가장 쉬운 것, 몇 개의 입력 상자와 버튼만 있으면 됩니다.
• Passwordless: 전화 / 이메일 입력, 그리고 동적 코드를 보내고 검증한다.
• 소셜 로그인: 선택한 소셜 아이덴티티 제공업체의 문서를 읽고, 시각 가이드라인을 따르고, 리디렉션 로직을 처리하고, 마지막으로 소셜 아이덴티티와 서점 아이덴티티를 연결합니다.

그것을 더 잘 만들기 위해 생각해 볼 것들이 더 있습니다:

• 특정 방법에 대해 로그인과 등록 과정을 결합해야 하는가?
• 고객이 스스로 비밀번호를 재설정할 수 있도록 "비밀번호 잊어버림" 과정이 필요한가?

만약 네이티브 개발을 선택한다면, 추가 플랫폼 하나당 작업량이 거의 두 배가 될 것입니다.

보안 및 토큰 교환#

보안은 숨어 있는 빙산이 될 수 있습니다. OpenID Connect나 OAuth 2.0에 익숙하다면 좋겠습니다, 왜냐하면 이들은 널리 사용되며 시험을 거쳤기 때문입니다. OpenID Connect는 상대적으로 새로움이지만, "사용자 인증"을 위해 설계되었으므로 온라인 서점에 적합합니다.

표준의 세부 사항을 깊게 파고들지 않고도, 고려해야 할 일들이 몇 가지 더 있습니다:

• 비밀번호에 어떤 암호화 방법을 사용해야 하는가?
• 표준 인증 및 권한 승인 프로세스는 무엇인가?
• 토큰 교환은 어떻게 작동하는가 (접근 토큰, 갱신 토큰, ID 토큰 등)?
• 토큰에서 서명 키를 어떻게 사용할 수 있으며, 어떻게 시그니처를 검증하여 리소스를 보호할 수 있는가?
• 클라이언트와 서버 공격은 어떻게 예방할 수 있는가?

마지막으로, 좋은 로그인 경험을 사용자에게 제공할 수 있습니다.

권한 모델#

서점으로서, 고객과 판매자를 위한 자원을 구별해야 합니다. 예를 들어, 고객은 모든 책을 둘러볼 수 있고, 판매자는 판매 중인 책을 관리할 수 있습니다. 비즈니스가 성장하면서, 여러분은 역할 기반 접근 제어(RBAC)나 속성 기반 접근 제어(ABAC)와 같은 더 유연한 모델을 사용해야 할 수 있습니다.

또한 나는 CIAM 102: 인증 및 역할 기반 접근 제어라는 기사를 썼어 기본적인 인증 개념과 RBAC 모델을 보여주기 위해.

결정을 내립니다#

auth는 "모든 것 또는 아무 것도 아닌" 문제가 아니라는 것을 볼 수 있습니다, 재정적 요소와 여러분이나 여러분의 팀이 이러한 영역에서 갖는 다른 기술 전문 지식을 포함하기 때문입니다. 현 상황을 더 잘 이해하기 위해 그것을 더 작은 부분으로 분해하는 것이 중요합니다.

누구에게 어떤 결정을 내릴 것인가를 생각하면, 나는 다음 질문들을 내 자신에게 묻습니다:

• 프로젝트가 얼마나 급한가?
• 나는 사업 대비 인증에 얼마나 많은 노력을 기울일 것으로 예상하는가?
• 사용자 경험, 보안, 유지 관리 가능성의 우선 순위는 무엇인가?
• 나는 어느 부분들을 완전히 제어 하림아지는가? 어떻게 그것들에 친숙해져야 하는가?
• 나는 일부 프레임워크 / 해결 방법들을 사용한다면, 그들은 사용자 정의나 확장에 충분히 좋은가?
• 비즈니스가 성장한다면, 나는 새로운 인증 모델을 도입해야 하는가?
• 나는 적절한 제공업체를 찾았다면, 그것을 사용하는 건 안전한가? 제공업체에 무슨 일이 생긴다면 철수 계획이 필요할까?

질문들이 머릿속에 있으면, 나는 두 가지 사실을 발견하였습니다:

• 믿을 수 있는 인증 시스템을 만드는 것은 높은 복잡성을 가지고 있습니다.
• 기존의 공급자들은 필요한 기준을 모두 충족시키지 못합니다.

그래서 나는 인증을 위한 전용 프로젝트(Logto)를 시작하기로 결정했고, 첫날부터 오픈 소스 커뮤니티를 받아들였습니다.

이 글이 도움이 되길 바랍니다.