이중 인증은 사용자 입장에서 매우 진부한 프로세스처럼 보일 수 있습니다. 많은 사람들은 많은 응용 프로그램을 사용할 때 익숙한 로그인 및 암호 조합을 입력하는 것만으로는 충분하지 않다는 사실에 오랫동안 익숙해졌습니다. 보안을 강화하고 무단 액세스를 방지하기 위해 추가 검증 요소가 도입되었습니다. 대부분의 경우 이메일이나 SMS로 받을 수 있는 고유 코드입니다.

이 튜토리얼에서는 AppMaster 에서 2단계 인증을 구현하는 방법을 배웁니다. 예를 들어 메일로 코드를 보내는 것이 사용됩니다. 어떤 모듈을 연결해야 하는지, 어떤 설정을 해야 하는지, 어떤 비즈니스 프로세스를 만들어야 하는지, 그리고 실제로 완성된 결과를 어떻게 확인하는지 분석해 보겠습니다.

먼저 전반적인 계획을 살펴보자. 비즈니스 프로세스에서 어떤 단계를 구현해야 합니까?

  1. 로그인 확인(사용자가 실제로 등록되었는지 확인).
  2. 비밀번호가 맞는지 확인 중입니다.
  3. 메일 또는 SMS로 확인 코드 보내기.
  4. 코드의 관련성을 확인합니다.
  5. 코드의 정확성을 확인합니다.
  6. 인증 완료.

준비 단계

이중 인증 설계를 시작하기 전에도 사용자 등록 단계에서 다음을 확인해야 합니다.

  • 사용자 데이터에는 이메일이 포함되어야 합니다. 인증 코드를 보내는 데 사용됩니다. 이메일은 종종 로그인으로 사용되며, 그러한 예를 살펴보겠습니다.
  • 로그인이 고유합니다. 동일한 로그인을 가진 두 명의 다른 사용자가 시스템에 존재할 수 없습니다.

이러한(및 기타 많은) 작업의 편의를 위해 각 AppMaster 프로젝트에 Auth 모듈이 기본적으로 설치됩니다. 여기에는 사용에 필요한 데이터베이스 모델, 비즈니스 프로세스 블록 및 끝점이 포함됩니다.

auth module

로그인 인증

로그인, 비밀번호 및 인증 코드는 비즈니스 프로세스의 입력 매개변수로 사용됩니다. 그러나 첫 번째 단계에서는 로그인만 필요합니다. 이 사용자가 존재하는지 확인하는 데 도움이 됩니다. 그는 등록되었으며 그에 대한 정보는 데이터베이스에 저장됩니다.

user check

이를 위해 DB: Search User 블록은 데이터베이스에서 주어진 로그인을 가진 사용자를 검색합니다. 정확히 일치하는 항목을 검색하려면 SearchExact = True 매개변수를 설정해야 합니다.

수신된 데이터는 인덱스가 0인 Array Element 블록으로 전달됩니다(카운트는 0부터 시작하고 발견된 유일한 값은 항상 배열의 인덱스 0에 해당함).

Is Null 블록은 사용자가 실제로 발견되었는지 여부를 확인합니다. 그리고 결과( True/False )에 따라 If-Else 블록은 오류 메시지( Raise Error 블록)와 함께 비즈니스 프로세스를 중단하거나 더 나아가 지시합니다.

비밀번호 확인

이 단계에서 사용자 암호가 올바르게 입력되었는지 확인해야 합니다.

password check

그리고 여기서 암호는 데이터베이스에 명시적으로 저장되지 않는다는 점을 이해하는 것이 중요합니다. Bcrypt 함수가 이를 해시하고 결과 해시만 데이터베이스에 저장됩니다. 따라서 데이터 유출이 발생한다고 가정하더라도 공격자는 여전히 사용자 암호를 찾을 수 없습니다. 그들은 안전하게 암호화됩니다.

이러한 이유로 단순히 데이터베이스에서 암호를 가져와 입력한 암호와 비교할 수 없습니다. 비밀번호의 해시를 가져와서 비교에 사용해야 합니다. 이 문제를 해결하기 위해 Auth: Probe Password 블록이 사용됩니다. 입력 매개변수로 사용자가 입력한 암호( password )와 데이터베이스에 저장된 암호의 해시( hashed_password )를 받아 이를 String 데이터 유형( To String 블록)으로 변환합니다.

결과에 따라 이전 단계에서와 같이 If-Else 블록을 사용하여 오류 메시지( Raise Error , Message = Password is wrong )를 표시하거나 프로세스를 다음 단계로 안내합니다.

사용자 모델 확장

다음 단계에서는 사용자 모델을 약간 변경하고 확인해야 하는 코드에 대한 정보를 추가해야 합니다.

일반적으로 User 모델에는 처음에 이 작업에 사용할 수 있는 필드 Confirmed, Confirmation code, Confirmation code expires at . 그러나 이 예에서는 이러한 필드가 등록 및 초기 계정 확인에만 사용된다고 가정합니다.

프로세스를 보다 명확하게 하기 위해 별도의 twofa ( two-factor authentication ) 모델을 만들고 User 모델을 해당 모델과 연결(1:1 관계, has one 있음)하고 하나의 필드 - code ( String 유형)를 추가하겠습니다.

user model

이메일 발송 준비

확인 코드가 포함된 이메일을 보내려면 미리 준비해야 합니다. 가장 접근 가능한 옵션 중 하나는 설치 및 구성해야 하는 Custom SMTP 모듈을 사용하는 것입니다.

custom SMTP module

Gmail 을 사용할 때 대부분의 설정은 기본적으로 이미 설정되어 있으며 사용자 이름과 비밀번호를 추가해야 합니다. 다른 메일 서버를 사용할 때 필요한 데이터를 얻기 위해 해당 문서를 참조하면 도움이 됩니다.

이 경우 메일 서버의 보안 설정을 약간 변경해야 할 수 있습니다. 예를 들어 Gmail 은 기본적으로 타사 애플리케이션을 사용하는 연결을 차단할 수 있으며 설정에서 이 제한을 제거해야 합니다.

인증 코드 전송

로그인과 비밀번호를 확인하고 필요한 모든 준비를 완료했으므로 이제 확인 코드가 포함된 편지를 보낼 수 있습니다.

send email

Custom SMTP: Send Email 블록은 주소 배열을 대상으로 사용합니다. 따라서 한 주소로 편지를 보내야 하는 경우에도 배열에 추가해야 합니다. 이를 위해 Append Array 블록이 사용됩니다.

다음 단계는 인증 코드를 생성하는 것입니다. Random string 블록이 이에 적합합니다. 6개의 난수로 구성된 코드를 보내드리고 적절한 설정을 해드립니다. Length = 6, With 0-9 = True , 다른 모든 매개변수 = False .

다음으로 편지의 텍스트를 만들어야 합니다. 이렇게 하려면 Concat Strings 블록을 사용하여 생성된 코드에 설명 텍스트를 추가하고( First = Verification code: ), 결과를 Text 데이터 유형( To Text 블록)으로 변환하고, 결과를 이메일의 body 매개변수에 연결합니다. 송신 블록.

최종 발신은 편지의 제목( subject )과 발신자( from_name )를 지정하는 일만 남습니다.

그러나 코드를 보내는 것만으로는 충분하지 않습니다. 또한 사용자 데이터에 저장해야 합니다. 결국 사용자가 코드를 수신하고 확인으로 다시 보낼 때 정확성을 확인해야 합니다.

save twofa

이를 위해 이전에 신중하게 만든 twofa 모델을 사용합니다. 첫 번째 코드 제출인 경우 코드가 속한 사용자에 대한 정보를 사용하여 코드를 생성해야 합니다. 재사용의 경우 기존 항목을 패치하여 ID와 새 코드를 표시해야 합니다.

단계의 마지막 단계는 Raise Error 블록을 사용하여 전자 메일로 코드를 보내는 것에 대한 메시지를 반환하는 것입니다.

코드 관련성 확인

추가 보안을 처리하고 진부한 열거로부터 코드를 보호할 가치가 있습니다. 입력 시도 횟수, 빈도 및 제출된 코드의 수명을 제한하는 것이 좋습니다. 우리는 이러한 모든 예를 분석하지 않을 것입니다. 보안 요구 사항은 각 프로젝트에 대해 개별적이며 다양한 조건을 포함할 수 있습니다. 유효 기간에 따라 코드의 관련성을 확인하는 것으로 제한됩니다.

code lifetime check

Current date & time 블록을 사용하여 현재 시간을 알아보겠습니다. Date & time difference 블록의 B 파라미터에 연결합니다. 우리는 매개변수 Atwofa 모델의 UpdatedAt 필드를 사용할 것입니다.

결과적으로 두 시점 간의 차이인 Time span 를 얻습니다. 이 차이가 선택한 특정 값을 초과하는지 확인하는 것만 남아 있습니다. 이 예에서는 5분이며, 이를 Greater 블록의 정적 값 B 로 설정합니다.

time span value

If-Else 블록은 비교 결과를 사용하여 프로세스를 추가로 안내합니다. True (차이가 5분 초과)인 경우 프로세스는 편지를 보내는 단계로 돌아갑니다. 사용자는 업데이트된 코드를 받게 됩니다. False 의 경우(코드가 최신이고 최신 상태임) 이 코드를 계속해서 확인할 수 있습니다.

코드 검토

인증의 마지막 단계는 수신된 코드를 확인하는 것입니다.

code check

Equal 블록은 사용자가 전달한 코드가 사용자와 연결된 twofa 모델에 저장된 코드와 일치하는지 확인해야 합니다. 그렇지 않고 코드가 잘못 지정된 경우( If-Else -> False ), 오류 메시지를 표시해야 합니다( Raise Error , Message = Code is wrong ). 비교 결과 일치가 확인되면 최종 인증 단계로 진행할 수 있습니다.

이를 위해 Auth: Authentication 블록을 사용하고 인증 토큰으로 사용자에 대한 정보를 얻습니다. 성공적인 인증의 결과로 이를 End 블록으로 전달합니다.

엔드포인트 생성

비즈니스 프로세스가 생성되었지만 아직 사용할 수 없습니다. 이 비즈니스 프로세스를 실행할 끝점을 만들어야 합니다.

2fa endpoint

합리적인 솔루션은 기본 인증 끝점( POST /Auth )을 사용하는 것입니다. 비즈니스 프로세스를 교체하고 방금 만든 프로세스를 설치하는 것으로 충분합니다. 따라서 단순 인증이 비활성화되고 2단계 인증이 대신 사용됩니다.

출판 및 테스트

이로써 이중 인증 생성이 완료됩니다. 결과를 게시하고 실제로 확인할 수 있습니다. 이를 위해 Preview 버튼의 Project API 섹션에서 Deploy 계획의 이름을 클릭하여 액세스할 수 있는 Swagger 를 사용하는 것이 편리합니다.

project API

목록에서 원하는 끝점을 찾고 사용자 데이터를 입력하고 Execute 버튼으로 실행을 시작하는 것만 남아 있습니다. 테스트 중에 오류가 발견되면 비즈니스 프로세스로 돌아가 필요한 변경을 수행합니다.

Swagger

Was this article helpful?

앱마스터.io 101 단기 특강

10 모듈
2 주

어디서부터 시작해야 할지 모르겠다고요? 초보자를 위한 단기 집중 과정을 시작하고 AppMaster를 A부터 Z까지 살펴보세요.

코스 시작
Development it’s so easy with AppMaster!

도움이 더 필요하세요?

전문가의 도움으로 모든 문제를 해결하십시오. 시간을 절약하고 애플리케이션 구축에 집중하십시오.

headphones

연락처 지원

문제에 대해 알려주시면 해결책을 찾아드리겠습니다.

message

커뮤니티 채팅

채팅에서 다른 사용자와 질문에 대해 토론하십시오.

커뮤니티 가입