SCA 및 OAuth: 안전한 인증 API 구축

오늘날의 디지털 환경에서 사용자 접근 보안은 무엇보다 중요합니다. PSD2 및 그와 동등한 글로벌 규정으로 인해 사기 위험이 증가하고 규제가 강화됨에 따라 강력 고객 인증(SCA)을 구현하는 것은 선택 사항이 아니라 필수 사항입니다. 특히 OAuth로 보호되는 민감한 데이터와 금융 거래를 처리할 때 더욱 그렇습니다. 이 글에서는 SCA를 OAuth 흐름에 원활하게 통합하여 강력한 보안과 끊김 없는 사용자 경험을 모두 보장하는 방법을 살펴봅니다. 아키텍처 고려 사항, API 디자인 패턴 및 개발자를 위한 실용적인 예를 다룰 것입니다.

핵심 요약 1: SCA는 여러 요소의 인증을 요구하여 OAuth에 보안 계층을 추가하고 사기 위험을 크게 줄입니다.

핵심 요약 2: SCA를 OAuth와 함께 구현할 때 원활한 사용자 경험을 위해서는 신중한 API 디자인과 통합이 중요합니다.

핵심 요약 3: Didit과 같은 전용 IDLicense 인증 서비스를 사용하면 SCA 구현을 간소화하고 규정 준수를 보장할 수 있습니다.

핵심 요약 4: 사용자 불편을 최소화하고 전환율을 극대화하려면 끊김 없는 통합을 우선시하십시오.

SCA와 OAuth의 필요성 이해

OAuth 2.0은 타사 애플리케이션이 자격 증명을 노출하지 않고 사용자 리소스에 대한 제한된 액세스 권한을 부여하는 널리 채택된 권한 부여 프레임워크입니다. 그러나 기존 OAuth 흐름은 종종 피싱, 자격 증명 스터핑 및 기타 공격에 취약한 사용자 이름과 비밀번호에만 의존하는 경우가 많습니다. SCA는 사용자가 신원을 확인하기 위해 최소 두 가지 독립적인 요소를 제공하도록 요구함으로써 이러한 취약점을 해결합니다. 이러한 요소는 세 가지 범주로 나뉩니다. 사용자가 알고 있는 것(비밀번호, PIN), 사용자가 소유한 것(스마트폰, 하드웨어 토큰), 사용자의 본인(생체 인식, 지문 스캔)입니다.

유럽의 PSD2와 같은 규정은 온라인 결제 및 민감한 뱅킹 데이터에 대한 액세스에 대해 SCA를 의무화합니다. 특정 요구 사항은 지역마다 다르지만 기본적인 원칙은 일관성을 유지합니다. 즉, 다단계 인증을 통해 보안을 강화하는 것입니다. SCA를 구현하지 않으면 상당한 벌금과 평판 손상이 발생할 수 있습니다.

SCA 통합을 위한 아키텍처 고려 사항

OAuth 흐름에 SCA를 통합하려면 신중한 아키텍처 계획이 필요합니다. 일반적인 접근 방식은 다음과 같습니다.

1. 권한 부여 요청: 클라이언트 애플리케이션이 OAuth 권한 부여 요청을 시작합니다.
2. 인증 도전: 권한 부여 서버는 SCA의 필요성을 감지합니다(예: 처음 액세스, 고위험 거래) 및 인증 도전을 발행합니다. 이 도전에는 사용자 등록 전화번호로 OTP를 보내거나, 생체 인증을 요청하거나, 푸시 알림 승인을 요청하는 것이 포함될 수 있습니다.
3. SCA 확인: 사용자는 전용 인터페이스 또는 모바일 뱅킹 앱을 통해 SCA 도전을 완료합니다.
4. 인증 부여: SCA 확인이 성공하면 권한 부여 서버는 액세스 토큰을 발행합니다.
5. 리소스 액세스: 클라이언트 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스에 액세스합니다.

주요 고려 사항에는 보안과 사용자 경험의 균형을 맞추는 SCA 방법을 선택하는 것이 포함됩니다. 푸시 알림 및 생체 인식은 끊김 없는 경험을 제공하는 반면 OTP는 더 널리 지원되지만 불편할 수 있습니다. 선택한 방법은 관련 규정을 준수해야 합니다.

SCA 준수 API 설계

API는 SCA 도전 및 응답을 지원하도록 설계되어야 합니다. 여기에는 기존 OAuth 엔드포인트를 확장하거나 새 엔드포인트를 도입하는 것이 포함됩니다. 가능한 접근 방식은 다음과 같습니다.

• /authorize: 이 엔드포인트는 SCA의 필요성을 감지하고 사용자를 적절한 인증 도전에 리디렉션해야 합니다. 클라이언트에게 알리기 위해 응답에 sca_required 매개변수도 포함해야 합니다.
• /token: 이 엔드포인트는 SCA 확인 프로세스를 처리해야 합니다. 권한 부여 서버에 대해 SCA 확인 코드를 매개변수로 받아 유효성을 검사해야 합니다.
• 오류 처리: SCA 실패를 처리하고 클라이언트 애플리케이션에 지침을 제공하기 위해 명확하고 유익한 오류 코드를 구현합니다.

SCA 확인에 대한 API 요청 예(단순화됨):

POST /token
{
  "grant_type": "authorization_code",
  "code": "authorization_code",
  "redirect_uri": "redirect_uri",
  "sca_verification_code": "123456"
}

IDLicense 인증 서비스 활용

SCA를 처음부터 구현하는 것은 복잡하고 시간이 많이 걸릴 수 있습니다. Didit과 같은 강력한 IDLicense 인증 서비스는 프로세스를 크게 간소화할 수 있습니다. Didit은 신원 확인, 활성 감지 및 다단계 인증을 위한 포괄적인 API 세트를 제공합니다. Didit의 API를 통합하면 SCA 구현의 복잡성을 오프로드하고 핵심 비즈니스 로직에 집중할 수 있습니다. Didit 플랫폼은 다음과 같은 기능을 제공합니다.

• API 통합: 모든 신원 확인 및 인증 요구 사항에 대한 단일 API입니다.
• 사용자 지정 워크플로: 특정 요구 사항에 맞춘 사용자 지정 확인 워크플로를 구축합니다.
• 사기 감지: 사기 거래를 식별하고 방지하기 위한 실시간 사기 신호입니다.
• 규정 준수: PSD2 및 기타 관련 규정 지원.

Didit과 같은 서비스를 활용하면 더 빠르고, 더 빠르며, 더 안전한 인증 프로세스를 보장할 수 있습니다. 플랫폼은 향상된 보안을 위한 서명 API도 지원합니다.

Didit이 어떻게 도움이 되는가

Didit은 다음과 같은 방법으로 OAuth와 함께 SCA 통합을 간소화합니다.

• 간소화된 API: 인증 및 확인의 모든 측면을 관리하기 위한 단일 통합 API입니다.
• 사전 구축된 워크플로: SCA 규정 준수를 위해 설계된 즉시 사용할 수 있는 워크플로로 개발 시간을 줄입니다.
• 위험 기반 인증: 저위험 사용자에 대한 마찰을 최소화하면서 위험 요소를 기반으로 필요한 인증 수준을 동적으로 조정합니다.
• 글로벌 적용 범위: 다양한 인증 방법 및 다양한 지역의 규정 요구 사항에 대한 지원입니다.

시작할 준비가 되셨습니까?

OAuth와 함께 SCA를 구현하는 것은 사용자를 보호하고 규정을 준수하는 데 중요합니다. Didit과 같은 강력한 IDLicense 인증 플랫폼을 활용하면 프로세스를 간소화하고 끊김 없고 안전한 인증 경험을 보장할 수 있습니다.

자세히 알아보고 오늘 시작하려면 https://docs.didit.me에서 Didit 설명서를 살펴보세요! https://demos.didit.me에서 데모를 받으세요.

FAQ

MFA와 SCA의 차이점은 무엇입니까?

자주 상호 교환적으로 사용되지만 SCA는 다단계 인증(MFA)의 하위 집합입니다. SCA는 독립적인 요소(예: 가지고 있는 것과 본인)를 구체적으로 요구하는 반면 MFA는 동일한 범주의 여러 요소를 포함할 수 있습니다(예: 두 개의 비밀번호). SCA는 PSD2와 같은 규정에서 의무화하는 보다 엄격한 요구 사항입니다.

SCA 구현 중 마찰을 어떻게 줄일 수 있습니까?

편리하고 직관적인 인증 방법을 우선시하십시오. 고위험 거래에 대해서만 도전을 위해 위험 기반 인증을 활용하십시오. 명확하고 유익한 오류 메시지를 제공하십시오. 원활한 경험을 위해 생체 인증 사용을 고려하십시오.

SCA 공급업체를 선택할 때 주요 고려 사항은 무엇입니까?

포괄적인 API 세트, 다양한 인증 방법 지원, 글로벌 적용 범위 및 보안 및 규정 준수의 입증된 기록을 갖춘 공급업체를 찾으십시오. 위험 기반 인증 및 사용자 지정 워크플로와 같은 기능을 제공하는지 확인하십시오.

모든 OAuth 흐름에 SCA가 필요한가요?

아니요, 모든 OAuth 흐름에 SCA가 필요한 것은 아닙니다. SCA의 필요성은 액세스되는 리소스의 민감도와 거래의 위험 프로필에 따라 달라집니다. PSD2와 같은 규정은 특정 유형의 거래(예: 온라인 결제 및 계정 정보 액세스)에 대해 SCA가 의무적인 경우를 지정합니다.