다음을 통해 공유

디바이스 지문의 웹 설정

  • 아티클

디바이스 지문 설정은 두 단계로 수행됩니다.

  1. DNS(Do기본 Name Server) SSL(Secure Sockets Layer) 인증서를 구성하고 사기 방지 포털에 업로드합니다.
  2. 디바이스 지문을 구현합니다.

이 섹션에서는 이러한 두 단계에 대한 자세한 지침을 제공합니다. 첫 번째 단계는 한 번만 완료해야 합니다. 그러나 디바이스 지문이 구현되는 각 웹 사이트 또는 모바일 앱에 대해 두 번째 단계를 한 번 반복해야 합니다.

DNS 설정 및 SSL 인증서 생성

DNS를 설정하고 SSL 인증서를 생성하려면 다음 절차를 완료합니다.

DNS 설정

DNS를 설정하려면 다음 단계를 수행합니다.

  1. 다음과 같이 fpt.contoso.com루트 do기본 아래에서 하위 기본 선택합니다. 모든 접두사를 사용할 수 있습니다.
  2. 선택한 하위 기본 대해 가리키는 CNAME(정식 이름)을 fpt.dfp.microsoft.com만듭니다.

SSL 인증서 생성 및 업로드

SSL 인증서를 생성하고 업로드하려면 다음 단계를 수행합니다.

  1. 백 엔드 온보딩의 경우 선택한 하위 기본 대한 SSL 인증서를 생성합니다. 하나의 SSL 인증서를 만들고 인증서의 주체 대체 이름 필드에 모든 하위 기본 추가할 수 있습니다.
  2. Fraud Protection 포털로 이동한 다음 왼쪽 탐색 창에서 통합을 선택합니다.
  3. 통합 페이지에서 편집을 선택한 다음, 다음 페이지에서 [다음]을 선택하여 SSL 인증서 업로드 페이지를 엽니다.
  4. 인증서 선택을 선택한 다음 생성한 SSL 인증서를 업로드합니다. 인증서에 암호가 있는 경우 텍스트 상자에 입력합니다. 그런 다음, 업로드를 선택합니다.

참고 항목

.pfx 파일만 지원됩니다. 인증서를 디바이스 지문 서버로 전파하는 데 몇 분 정도 걸릴 수 있습니다.

디바이스 지문 구현

웹 사이트 또는 애플리케이션은 위험 평가를 위해 사기 방지로 트랜잭션이 전송되기 몇 초 전에 디바이스 지문 처리 요청을 시작해야 합니다(예: 결제 방법 추가, 로그인 또는 검사아웃). 이 요구 사항은 Fraud Protection이 정확한 평가를 수행하는 데 필요한 모든 데이터를 수신하도록 보장합니다. 이 섹션에서는 웹 사이트 및 모바일 앱에서 디바이스 지문을 구현하기 위한 자세한 지침을 제공합니다.

디바이스 지문을 구현하려면 다음 단계를 수행합니다.

  1. 다음 JavaScript 스크립트 코드를 수정하고 디바이스 지문 정보를 수집하려는 웹 페이지 또는 애플리케이션에 삽입합니다.

    <script src="https://<Your_Sub_Domain>/mdt.js?session_id=<session_id>&instanceId=<instance_id>" type="text/javascript"></script>
    • Your_Sub_Do기본 – 루트 아래의 하위 기본기본.
    • session_id – 클라이언트에서 만든 디바이스의 고유한 세션 식별자입니다. 최대 128자까지 가능하며 대문자 및 소문자 로마 문자, 숫자, 밑줄 문자 및 하이픈(a-z, A-Z, 0-9, _, -)만 포함할 수 있습니다. 세션 ID는 임의로 생성된 데이터의 16바이트 이상을 포함해야 합니다. 16진수 인코딩을 사용하는 경우 32개의 16진수 문자로 변환됩니다. 세션 ID에 GUID(Globally Unique Identifier)를 사용하는 것이 좋지만 필수는 아닙니다.
    • instance_id – 디바이스 지문과 웹 사이트를 통합하는 데 필요한 값입니다. 사기 방지 포털의 해당 환경 통합 페이지에 있는 현재 환경 타일에 나열된 디바이스 지문 ID 값을 사용합니다.

    예제

    <script src="https://fpt.contoso.com/mdt.js?session_id=211d403b-2e65-480c-a231-fd1626c2560e&instanceId=b472dbc3-0928-4577-a589-b80090117691" type="text/javascript"></script>

    다음은 mdt.js 대한 응답의 예입니다.

    window.dfp={url:"https://fpt.contoso.com/?session_id=211d403b-2e65-480c-a231-fd1626c2560e&CustomerId=b472dbc3-0928-4577-a589-b80090117691",sessionId:"211d403b-2e65-480c-a231-fd1626c2560e",customerId:"b472dbc3-0928-4577-a589-b80090117691",dc:"uswest"};window.dfp.doFpt=function(doc){var frm,src;true&&(frm=doc.createElement("IFRAME"),frm.id="fpt_frame",frm.style.width="1px",frm.style.height="1px",frm.style.position="absolute",frm.style.visibility="hidden",frm.style.left="10px",frm.style.bottom="0px",frm.setAttribute("style","color:#000000;float:left;visibility:hidden;position:absolute;top:-100;left:-200;border:0px"),src="https://Your_Sub_Domain/?session_id=211d403b-2e65-480c-a231-fd1626c2560e&CustomerId=b472dbc3-0928-4577-a589-b80090117691",frm.setAttribute("src",src),doc.body.appendChild(frm))};

  2. 페이지의 요소가 로드된 후 디바이스 지문을 로드합니다.

    window.dfp.doFpt(this.document);

  3. Fraud Protection API에서 트랜잭션을 제출할 때 deviceContextId 필드에서 세션 ID를 설정합니다. 평가의 경우 deviceFingerprinting.id 필드에 세션 ID를 설정합니다.

  4. device.ipAddress 필드를 고객이 사이트를 사용할 때 웹 사이트에서 받는 고객 IP 주소로 설정합니다. 평가의 경우 deviceFingerprinting.ipAddress 필드에서 고객 IP 주소를 설정합니다. 이 필드는 선택 사항이며, 필드가 없으면 설정할 필요가 없습니다.

디바이스 지문에 클라이언트 쪽 통합 사용

특정 웹 지문 시나리오의 경우 Fraud Protection은 클라이언트 쪽 통합이라는 특수한 통합 클래스를 지원합니다. 지문 응답이 암호화된 페이로드로 클라이언트에 직접 반환되고 서버-서버 평가 호출을 건너뛰기 때문에 클라이언트 쪽 통합은 표준 통합 방식과 다릅니다.

클라이언트 쪽 통합은 서버 간 호출을 건너뛰는 것이 유리한 짧은 대기 시간 시나리오에 유용합니다. 클라이언트 쪽 통합이 시나리오에 적합한지 여부를 확인하려면 다음 질문 가이드를 참조하세요.

  1. 내 시나리오 디바이스 지문만 있나요?

    시나리오가 디바이스 지문만 아닌 경우 클라이언트 쪽 통합이 시나리오에 적합하지 않습니다.

  2. 내 지문 데이터가 내 서버에서 가져오는 것과 반대로 브라우저에 표시되게 하시겠습니까?

    기존 서버-서버 통합에서 웹 사이트에서 특성 수집이 완료되면 데이터는 Fraud Protection의 서버로 푸시됩니다. 여기서 표준 평가 API 호출을 수행하여 서버에서 평가 응답을 얻을 수 있습니다. 그러나 클라이언트 쪽 통합에서 특성 수집 데이터가 Fraud Protection의 서버로 푸시되면 평가 응답이 다시 돌아와 브라우저에서 직접 반환됩니다. 이렇게 하면 서버에서 서버로 호출하는 대신 브라우저 자체에서 평가 응답을 추출하여 시간을 절약할 수 있습니다. 지문 자체는 몇 초 정도 걸리므로 사용자가 몇 초 동안 페이지에 있는 경우에만 평가 응답이 브라우저에 표시됩니다. 시나리오가 브라우저에 이미 있는 데이터의 이점을 누릴 경우 클라이언트 쪽 통합이 적합할 수 있습니다.

일반적으로 대부분의 지문 처리 시나리오는 표준 서버 간 통합을 통해 해결되며 클라이언트 쪽 통합은 대기 시간 감소가 중요한 몇 가지 특정 시나리오에 유용합니다. 클라이언트 쪽 통합은 간소화되고 안전한 특수한 통합 클래스이므로 사용하도록 설정하려면 다음 필수 구성 요소를 충족해야 합니다.

  • 사기 방지 테넌트 루트 환경에 있어야 합니다.
  • JWKS(JSON 웹 키 집합) 형식으로 암호화 키 응답을 반환하는 외부 호출을 설정해야 합니다. 이 외부 호출은 Fraud Protection이 페이로드를 암호화하는 데 사용하는 키를 반환합니다. 나중에 이 키를 사용하여 처음에 클라이언트 쪽을 수신한 Fraud Protection 응답 서버 쪽의 암호를 해독할 수 있습니다. 암호화 및 암호 해독에 대한 키를 제공할 책임이 있습니다. 외부 호출을 설정하는 방법에 대한 자세한 내용은 외부 호출을 참조하세요.

다음 코드는 JWKS 형식의 예를 보여 줍니다.

{
  "keys":
  [
    {
      "kty":null,
      "use":null,
      "kid":null,
      "k":null
    }
  ]
}
  • 디바이스 지문 평가 템플릿의 메타데이터 및 디바이스 지문 섹션만 사용해야 합니다. 추가 스키마 섹션이 있거나 디바이스 지문 평가 템플릿을 사용하지 않는 경우 클라이언트 쪽 통합 옵션을 사용할 수 없습니다.

디바이스 지문 템플릿에 대한 평가 마법사의 설정 페이지에 도달하면 사용할 수 있는 클라이언트 쪽 통합 옵션이 표시됩니다. 클라이언트 쪽 통합을 사용하도록 선택한 후 설정한 JWKS 응답 형식으로 외부 호출을 선택합니다.

클라이언트 쪽 통합 설정을 완료하려면 브라우저에서 암호화된 응답을 반환하려면 다음 JavaScript 예제의 수정된 버전을 사용해야 합니다.

<script src="https://<Your_Sub_Domain>/mdt.js?session_id=<session_id>&customerId=<customer_id>&assessment=<assessment>&requestId=<request_id>" type="text/javascript"></script>
  • Your_Sub_Do기본 – 루트 아래의 하위 기본기본.
  • session_id – 클라이언트에서 만든 디바이스의 고유한 세션 식별자입니다. 최대 128자까지 가능하며 대문자 및 소문자 로마 문자, 숫자, 밑줄 문자 및 하이픈(a-z, A-Z, 0-9, _, -)만 포함할 수 있습니다. 세션 ID는 임의로 생성된 데이터의 16바이트 이상을 포함해야 합니다. 16진수 인코딩을 사용하는 경우 32개의 16진수 문자로 변환됩니다. 세션 ID에 GUID(Globally Unique Identifier)를 사용하는 것이 좋지만 필수는 아닙니다.
  • customer_id – 디바이스 지문과 웹 사이트를 통합하는 데 필요한 값입니다. Fraud Protection 포털에서 해당 환경의 통합 페이지의 현재 환경 타일에 나열된 환경 ID 값을 사용합니다. 클라이언트 쪽 통합이 작동하려면 루트 환경에 있어야 합니다.
  • 평가 – 클라이언트 쪽 통합을 사용하도록 설정된 디바이스 지문 평가의 API 이름입니다. API 이름은 대/소문자를 구분하며 평가 구성 페이지에서 가져옵니다.
  • request_id – 세션 ID와는 별도로 요청 자체에 대한 고유 식별자입니다. 이 식별자는 길이가 32자 이상인 GUID여야 합니다.

다음 샘플에서는 예제 값이 있는 JavaScript 코드를 보여줍니다.

<script src="https://fpt.contoso.com/mdt.js?session_id=2b2a1f5e-afa7-4c6d-a905-ebf66eaedc83&customerId=b3f6d54b-961c-4193-95ee-b6b204c7fd23&assessment=CSI&requestId=b12e86a0-37b1-43a2-958b-3f04fe7cef6c" type="text/javascript"></script>

이 스크립트를 설정하고 클라이언트 쪽 통합을 사용하도록 설정하면 지문 응답이 클라이언트 브라우저에서 암호화된 페이로드로 반환됩니다. 콜백 함수를 사용하여 암호화된 응답 페이로드를 잡을 수 있습니다. 아래 예제에서는 사용 중인 콜백 함수를 보여줍니다.

window.dfp.doFpt(document, function (response) {
    if(response == null || response.startsWith('ServerError'))
        console.log("Error Scenario");
    else
        console.log("Success Scenario"); // pass to server so it can decrypt and use response
});

암호를 해독하고 응답을 사용하려면 여전히 페이로드를 서버에 전달해야 합니다. 페이로드 암호를 해독하기 위해 호스트하는 암호화 키를 가져오기 위해 외부 호출을 호출하지 않을 것으로 예상됩니다. 서버에서 사용되는 다른 비밀을 가져와서 관리하는 것과 동일한 보안 방식으로 키를 저장하고 액세스해야 합니다.

추가 리소스