• accessKey 와 seckeyKey 를 Basic Auth 로 받으면
  다시 분해 해서 DB의 값과 비교하고 맞으면 API 호출.

{
	"accessKeyId":"KASKKU3OB9V6DZPMY8B8MRNV",
	"secretAccessKey":"0YjPYFXVLjLYH3tFcH_RzQQBoE58FivJtwJVSxry",
	"authorization":"Basic S0FTS0tVM09COVY2RFpQTVk4QjhNUk5WOjBZalBZRlhWTGpMWUgzdEZjSF9SelFRQm9FNThGaXZKdHdKVlN4cnk="
}

참고

• 인증(Authentication)과 인가(Authorization)

• REST API의 이해와 설계-#3 API 보안

• [JWT] 토큰(Token) 기반 인증에 대한 소개

• REST 요청 - AWS 액세스 키 ID 및 AWS 보안 액세스 키

twilio - verify

• QR코드 직접 구현
• Identify: UUID, SID GUID 같은 것처럼 8~64자의 '-' 가 포함되도 되는 Unique 한 문자열 을 입력(UUID, SID, GUID는 직접 식별이 불가능하도록 해야하며, 외부 시스템에 의해 생성되어야한다.)

토큰 리워드에 적용할 흐름도

TOTP 기술 흐름

1. 최초 로그인 / Factor를 삭제한 경우
2. create TOPT Factor
3. QRCode 생성 및 띄우기
4. TOTP Factor 검증(최초 검증) - DB에 Factor SID 수집해야하나...
   - 팩터가 처음 생성될 때 "미확인" 상태입니다. 팩터를 확인하려면 사용자가 시드를 기반으로 올바른 코드를 생성할 수 있음을 입증해야 합니다.
   인증 앱에서 생성한 코드를 사용하고 이 단계의 코드 샘플을 입력하거나 붙여넣습니다.
5. 토큰 검증을 위한 챌린지 생성 - 이후 approved(승인)되면 JWT 토큰 발급
   • 사용자를 확인하려면 사용자가 인증 프로그램에서 생성한 최신 코드를 읽고 사용자에게 제공해야 합니다. 그런 다음 챌린지를 만들고 코드를 AuthPayload 로 포함해야 합니다. 코드가 정확하면 챌린지가 approved 상태로 만들어집니다. 코드가 잘못되면 pending 상태로 만들어지고 결국 만료되는 과제가 발생합니다. 코드가 잘못된 경우 사용자에게 새 코드를 제공하고 새 챌린지를 만들어 올바른지 확인하도록 요청할 수 있습니다. 또는 기존 챌린지를 새로운 AuthPayload 값으로 업데이트할 수 있지만 이 방법은 구현하기가 더 복잡할 수 있습니다. 이 단계의 코드 샘플을 입력하거나 붙여넣습니다.

고려 사항

• 나중에 Factor 변경 이나 삭제 는 어떻게 해야할지도 고민해야한다.

  • 변경은 그냥 삭제처리하고 새로 발급 하게 하는 것으로 (재 발급 과정은 삭제하고 새로 발급)

• Factor 삭제

• DB 수정 추가

  • 사용자: Entity 값으로 들어갈 UUID , Factor SID, Factor 가 있는지 없는지 여부
  • 그룹별: Service SID

• 추가적인 화면 어떻게 ??

• 팩터 미등록

1. id(email), pw 1차 로그인 후
2. factor 등록 여부를 확인하고 안되어 있다면 Factor 등록 해달라는 문구와 버튼있는 화면?
3. QRCODE 화면
4. TOTP factor 검증 화면 (최초등록 OTP)
5. Challenge 화면(OTP 입력화면)

• 팩터 등록

1. 1차인증
2. TOTP Challenge 화면(OTP 입력화면)

• 팩터 삭제

1. 1차인증
2. TOTP Challenge 화면에 팩터 삭제(또는 재등록?) 이라는 버튼을 클릭
   • 팩터 삭제 후, User에서 Factor SID 삭제와, factor 등록 여부 미등록 처리

3-1. 삭제면 등록 해달라는 화면을 보여줄지
3-2. 재등록이면 바로 QRcode 화면 보여주기?

• Authy 설치와 QRcode Factor 등록하는 설명서 화면