콘솔로 이동

기존 HTTP에서 HTTP v1로 마이그레이션

FCM의 기존 HTTP API를 사용하는 앱은 이 가이드의 안내에 따라 HTTP v1 API로 마이그레이션해야 합니다. HTTP v1 API는 기존 API에 비해 다음과 같은 장점이 있습니다.

  • 액세스 토큰을 통한 보안 향상: HTTP v1 API는 OAuth2 보안 모델에 따라 수명이 짧은 액세스 토큰을 사용합니다. 액세스 토큰이 공개되는 경우에도 만료되기 전에 1시간 정도만 악의적으로 사용될 수 있습니다. 새로고침 토큰이 이전 API에서 사용하는 보안 키만큼 자주 전송되지 않으므로 캡처될 가능성이 매우 낮습니다.

  • 여러 플랫폼에서 보다 효율적인 메시지 맞춤설정: 메시지 본문의 경우 HTTP v1 API에 모든 대상 인스턴스에 전달되는 공용 키는 물론 여러 플랫폼의 메시지를 맞춤설정할 수 있는 플랫폼별 키가 있습니다. 이러한 키를 사용하면 메시지 하나로 여러 클라이언트 플랫폼에 약간 다른 페이로드를 전송하는 '재정의'를 만들 수 있습니다.

  • 새 클라이언트 플랫폼 버전을 위한 확장성 강화 및 미래 경쟁력 확보: HTTP v1 API는 iOS, Android, 웹에 제공되는 메시지 옵션을 완전히 지원합니다. 각 플랫폼별로 JSON 페이로드에 자체 정의된 블록이 있으므로 FCM에서 필요에 따라 새 버전과 새 플랫폼으로 API를 확장할 수 있습니다.

서버 엔드포인트 업데이트

HTTP v1 API의 엔드포인트 URL은 다음과 같은 면에서 기존 엔드포인트와 다릅니다.

  • 경로의 /v1로 버전이 지정됩니다.
  • 경로에 /projects/myproject-ID/ 형식으로 앱의 Firebase 프로젝트 ID가 포함됩니다. Firebase Console의 일반 프로젝트 설정 탭에서 이 ID를 확인할 수 있습니다.
  • send 메서드를 :send로 명시적으로 지정합니다.

HTTP v1의 서버 엔드포인트를 업데이트하려면 전송 요청 헤더의 엔드포인트에 이러한 요소를 추가하세요.

이전

POST https://fcm.googleapis.com/fcm/send

이후

POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send

전송 요청의 승인 업데이트

HTTP v1 전송 요청의 경우 이전 요청에서 사용하는 서버 키 문자열 대신 OAuth 2.0 액세스 토큰이 필요합니다. Admin SDK를 사용하여 메시지를 보내는 경우 라이브러리에서 토큰이 자동으로 처리됩니다. 원시 프로토콜을 사용하는 경우 이 섹션에 설명된 대로 토큰을 가져와서 헤더에 Authorization: Bearer <valid Oauth 2.0 token>으로 추가합니다.

이전

Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA

이후

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

서버 환경의 세부정보에 따라 다음 전략을 조합하여 Firebase 서비스에 대한 서버 요청을 승인합니다.

  • Google 애플리케이션 기본 사용자 인증 정보(ADC)
  • 서비스 계정 JSON 파일
  • 서비스 계정에서 생성된 수명이 짧은 OAuth 2.0 액세스 토큰

애플리케이션이 Compute Engine, Kubernetes Engine, App Engine 또는 Cloud Functions(Firebase용 Cloud Functions 포함)에서 실행되는 경우 애플리케이션 기본 사용자 인증 정보(ADC)를 사용합니다. ADC는 기존의 기본 서비스 계정을 사용하여 요청을 승인하기 위한 사용자 인증 정보를 가져오며 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 통한 유연한 로컬 테스트를 지원합니다. 승인 과정을 최대한 자동화하기 위해 ADC를 Admin SDK 서버 라이브러리와 함께 사용하세요.

애플리케이션이 Google 이외의 서버 환경에서 실행되는 경우 Firebase 프로젝트에서 서비스 계정 JSON 파일을 다운로드해야 합니다. 비공개 키 파일이 포함된 파일 시스템에 액세스할 수 있으면 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 수동으로 가져온 사용자 인증 정보로 요청을 승인할 수 있습니다. 이러한 파일에 액세스할 수 없으면 코드에서 서비스 계정 파일을 참조해야 합니다. 이때 사용자 인증 정보가 노출될 위험이 있으므로 매우 주의해야 합니다.

ADC를 사용하여 사용자 인증 정보 제공

Google 애플리케이션 기본 사용자 인증 정보(ADC)는 다음 순서에 따라 사용자 인증 정보를 확인합니다.

  1. ADC에서 GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 설정되었는지 확인합니다. 이 변수가 설정된 경우 ADC는 변수가 가리키는 서비스 계정 파일을 사용합니다.

  2. 환경 변수가 설정되지 않은 경우 ADC는 Compute Engine, Kubernetes Engine, App Engine, Cloud Functions가 이러한 서비스에서 실행되는 애플리케이션에 제공하는 기본 서비스 계정을 사용합니다.

  3. ADC에서 위 사용자 인증 정보 중 하나를 사용할 수 없는 경우 시스템에 오류가 발생합니다.

다음 Admin SDK 코드 예시에서는 이 전략을 설명합니다. 예에서는 애플리케이션 사용자 인증 정보를 명시적으로 지정하지 않습니다. 그러나 환경 변수가 설정되어 있거나 애플리케이션이 Compute Engine, Kubernetes Engine, App Engine, Cloud Functions에서 실행 중인 경우 ADC는 사용자 인증 정보를 암묵적으로 찾을 수 있습니다.

Node.js

admin.initializeApp({
  credential: admin.credential.applicationDefault(),
});

자바

FirebaseOptions options = new FirebaseOptions.Builder()
    .setCredentials(GoogleCredentials.getApplicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
    .build();

FirebaseApp.initializeApp(options);

Python

default_app = firebase_admin.initialize_app()

Go

app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
	log.Fatalf("error initializing app: %v\n", err)
}

C#

FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.GetApplicationDefault(),
});

수동으로 사용자 인증 정보 제공

Firebase 프로젝트는 앱 서버 또는 신뢰할 수 있는 환경에서 Firebase 서버 API를 호출하는 데 사용할 수 있는 Google 서비스 계정을 지원합니다. 로컬에서 코드를 개발하거나 온프레미스에 애플리케이션을 배포하는 경우 이 서비스 계정을 통해 가져온 사용자 인증 정보를 사용하여 서버 요청을 승인할 수 있습니다.

서비스 계정을 인증하고 Firebase 서비스에 액세스하도록 승인하려면 JSON 형식의 비공개 키 파일을 생성해야 합니다.

서비스 계정의 비공개 키 파일을 생성하려면 다음 안내를 따르세요.

  1. Firebase Console에서 설정 > 서비스 계정을 엽니다.

  2. 새 비공개 키 생성을 클릭한 다음 키 생성을 클릭하여 확인합니다.

  3. 키가 들어 있는 JSON 파일을 안전하게 저장합니다.

서비스 계정을 통한 승인 시 2가지 방법을 사용하여 애플리케이션에 사용자 인증 정보를 제공할 수 있습니다. GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 설정하거나 코드에서 서비스 계정 키에 경로를 명시적으로 전달할 수 있습니다. 그러나 보안성 측면에서 첫 번째 방법을 권장합니다.

환경 변수를 설정하는 방법은 다음과 같습니다.

GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 서비스 계정 키가 포함된 JSON 파일의 파일 경로로 설정합니다. 이 변수는 현재 셸 세션에만 적용되므로 새 세션을 열면 변수를 다시 설정합니다.

Linux 또는 macOS

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

Windows

PowerShell:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

위 단계를 완료하면 애플리케이션 기본 사용자 인증 정보(ADC)가 암묵적으로 사용자 인증 정보를 확인할 수 있으므로 Google 이외의 환경에서 테스트 또는 실행할 때 서비스 계정 사용자 인증 정보를 사용할 수 있습니다.

사용자 인증 정보를 사용하여 액세스 토큰 발급

원하는 언어의 Google API 클라이언트 라이브러리와 함께 Firebase 사용자 인증 정보를 사용하여 수명이 짧은 OAuth 2.0 액세스 토큰을 검색합니다.

node.js

 function getAccessToken() {
  return new Promise(function(resolve, reject) {
    var key = require('./service-account.json');
    var jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}

Python

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token

자바

private static String getAccessToken() throws IOException {
  GoogleCredential googleCredential = GoogleCredential
      .fromStream(new FileInputStream("service-account.json"))
      .createScoped(Arrays.asList(SCOPES));
  googleCredential.refreshToken();
  return googleCredential.getAccessToken();
}

액세스 토큰이 만료되면 토큰 갱신 메서드가 자동으로 호출되어 업데이트된 액세스 토큰이 발급됩니다.

FCM에 대한 액세스를 승인하려면 https://www.googleapis.com/auth/firebase.messaging 범위를 요청하세요.

HTTP 요청 헤더에 액세스 토큰을 추가하는 방법은 다음과 같습니다.

Authorization 헤더의 값으로 토큰을 Authorization: Bearer <access_token> 형식으로 추가합니다.

node.js

headers: {
  'Authorization': 'Bearer ' + accessToken
}

Python

headers = {
  'Authorization': 'Bearer ' + _get_access_token(),
  'Content-Type': 'application/json; UTF-8',
}

자바

URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;

전송 요청의 페이로드 업데이트

FCM HTTP v1에서 JSON 메시지 페이로드의 구조에 중대한 변화가 있습니다. 이러한 변화를 통해 기본적으로 여러 클라이언트 플랫폼에 수신될 때 메시지가 올바르게 처리될 수 있을 뿐만 아니라 플랫폼별로 보다 유연하게 메시지 필드를 맞춤설정하거나 '재정의'할 수 있습니다.

HTTP v1에 익숙해지려면 이 섹션의 예시를 살펴보는 것 외에 여러 플랫폼의 메시지 맞춤설정API 참조를 확인하세요.

예시: 간단한 알림 메시지

다음은 title, body, data 필드만 있는 매우 간단한 알림 페이로드를 비교한 것으로, 기존 페이로드와 HTTP v1 페이로드의 근본적인 차이점을 보여줍니다.

이전

{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available."
  },
  "data": {
    "story_id": "story_12345"
  }
}

이후

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
  }
}

예시: 여러 플랫폼 타겟팅

여러 플랫폼 타겟팅을 사용 설정하기 위해 이전 API는 백엔드에서 재정의를 수행했습니다. 반면 HTTP v1는 플랫폼 간의 차이점을 분명하게 만들고 개발자에게 이러한 차이점을 보여주는 플랫폼별 키 블록을 제공합니다. 이를 통해 다음 샘플에 나와 있는 것처럼 요청 하나로 언제든지 여러 플랫폼을 타겟팅할 수 있습니다.

이전

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// iOS
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

이후

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY"
      }
    },
    "aps": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

예시: 플랫폼 재정의로 맞춤설정

HTTP v1 API를 사용하면 메시지의 교차 플랫폼 타겟팅이 단순해지는 것 외에도 플랫폼별 메시지를 유연하게 맞춤설정할 수 있습니다.

이전

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "Check out the Top Story.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// iOS
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

이후

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY",
        "body": "Check out the Top Story"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

FCM HTTP v1 API의 추가 샘플과 자세한 내용은 Firebase 블로그를 참조하세요.