커스텀 앱 체크 제공자 구현
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
App Check에는 Apple 플랫폼의 DeviceCheck 및 App Attest, Android의 Play Integrity, 웹 앱의 reCAPTCHA Enterprise 등 여러 제공자가 기본적으로 지원됩니다(개요). 대부분의 개발자 요구를 충족하는 잘 알려진 제공자입니다. 그러나 자체 커스텀 App Check 제공자를 구현할 수도 있습니다. 다음과 같은 경우 커스텀 제공자를 사용해야 합니다.
기본 제공자 이외의 다른 제공자를 사용하려고 합니다.
지원되지 않는 방식으로 기본 제공자를 사용하려고 합니다.
Apple, Android, 웹 이외의 플랫폼을 사용하여 기기를 인증하려고 합니다. 예를 들어 데스크톱 OS 또는 사물 인터넷 기기를 위한 App Check 제공자를 만들 수 있습니다.
모든 플랫폼에서 자체 인증 기법을 구현하려고 합니다.
개요
커스텀 App Check 제공자를 구현하려면 Node.js Firebase Admin SDK를 실행할 수 있는 보안 백엔드 환경이 필요합니다.
Cloud Functions, Cloud Run과 같은 컨테이너 플랫폼 또는 자체 서버일 수 있습니다.
이 환경에서 앱 클라이언트로부터 신뢰성 증명을 수신하고 신뢰성 증명이 통과되면 App Check 토큰을 반환하는 네트워크에 액세스 가능한 서비스를 제공합니다. 신뢰성 증명으로 사용하는 특정 표시기는 사용 중인 타사 공급업체 또는 자체 개발 표시기(커스텀 로직을 구현하는 경우)에 따라 달라집니다.
일반적으로 이 서비스를 REST 또는 gRPC 엔드포인트로 노출하지만, 세부정보는 직접 결정합니다.
토큰 획득 엔드포인트 만들기
Admin SDK를 설치하고 초기화합니다.
클라이언트로부터 인증 데이터를 수신할 수 있으며 네트워크에 액세스할 수 있는 엔드포인트를 만듭니다. 예를 들어 다음과 같이 Cloud Functions을 사용합니다.
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
// ...
});
신뢰성 데이터를 평가하는 엔드포인트 로직에 추가합니다. 이는 커스텀 App Check 제공자의 핵심 로직이며, 개발자가 직접 작성해야 합니다.
클라이언트를 신뢰할 수 있다고 판단하면 Admin SDK를 사용하여 App Check 토큰을 발급하고 클라이언트에 토큰과 만료 시간을 반환합니다.
const admin = require('firebase-admin');
admin.initializeApp();
// ...
admin.appCheck().createToken(appId)
.then(function (appCheckToken) {
// Token expires in an hour.
const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;
// Return appCheckToken and expiresAt to the client.
})
.catch(function (err) {
console.error('Unable to create App Check token.');
console.error(err);
});
클라이언트의 신뢰성을 확인할 수 없는 경우 오류를 반환합니다(예: HTTP 403 오류 반환).
선택사항: AppCheckTokenOptions
객체를 createToken()
에 전달하여 커스텀 제공자에서 발급한 App Check 토큰의 TTL(수명)을 설정합니다. TTL은 30분에서 7일 사이의 값으로 설정할 수 있습니다. 이 값을 설정할 때는 다음 장단점을 고려하세요.
- 보안: TTL이 짧을수록 유출되거나 가로채인 토큰이 공격자에 의해 악용될 수 있는 기간이 줄어들므로 보안이 강화됩니다.
- 성능: TTL이 짧을수록 앱에서 증명을 더 자주 수행합니다. 앱 증명 프로세스는 실행될 때마다 네트워크 요청에 지연 시간이 추가되므로 짧은 TTL은 앱 성능에 영향을 줄 수 있습니다.
대부분의 앱에 기본 TTL인 1시간이 적합합니다.
다음 단계
이제 커스텀 제공자의 서버 측 로직을 구현했으므로 Apple, Android, 웹 클라이언트에서 커스텀 제공자를 사용하는 방법을 알아보세요.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-08-23(UTC)
[null,null,["최종 업데이트: 2025-08-23(UTC)"],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]