[Remote Notification 한판 정리] APNs / Token Based / Certificate Based / .p8과 .p12

공부

[Remote Notification 한판 정리] APNs / Token Based / Certificate Based / .p8과 .p12

Zedd0202 2022. 10. 8. 19:17

아주 예전에..FCM으로 Remote notification작업을 해본적은 있긴 한데

DeviceToken이나 APNs같은 기본적인것들은 알았어도

전체적인 플로우에 대한 정확한 이해가 없이 진행했던것 같다.

Remote Notification관련하여 테스트해보고 싶은게 생겼는데,

관련하여 똑같은 작업을 하기전에 나 스스로 정리해보고싶은것들이 몇가지 있어 정리해보려고 한다.

# Notification종류

- local → 앱에서 직접 만드는 notification

- remote → 서버 등 원격(remote)에서 만들어지는 notification

# APNs

Apple Push Notification service의 약자로. 앱에 notification을 보낼 수 있도록 애플이 만든 서비스이다.

Remote notification의 경우 아묻따 이 APNs를 거쳐와야한다. (local은 거치지 X)

APNs가 내가 보내려는 notification을 사용자로 기기로 전달하는 역할을 하기 때문이다.

# Remote Notification을 위한 준비물

그럼 Remote notification(이하 알림)의 경우 4가지의 준비물이 필요하다.

1. Provider server (그냥 알림을 만들어내는 어떤것이든 여기에 포함될 수 있다. FCM, 본인 회사 서버같은것들 포함)

2. APNs

3. 사용자의 기기

4. 사용자의 기기에 설치된 너의 앱 (권한도 필요하지만, 이건 나중에..)

# 전체적인 플로우

그럼 생각해보자.

알림의 컨텐츠와 언제보낼지, 누구한테 보낼지 등을 결정하는 것은 온전히 우리의 서버(provider)일것이다.

즉, 알림은 provider에서부터 시작된다.

그래서 provider는 알림을 보내야할 때,

- 알림 컨텐츠

- 알림을 보낼 디바이스의 unique identifier (내가 특정 사람에게 알림을 보내야하니까. 아마도 DeviceToken)

를 포함한 요청을 생성하게 되고, 이 요청은 APNs로 전달된다.

위에서도 말했지만, APNs가 내가 보내려는 알림을 사용자로 기기로 전달하는 역할을 하기 때문이다.

APNs는 알림을 사용자의 기기로 전달하게 되고,

기기가 알림을 수신하게 되면 기기의 OS가 모든 사용자 상호작용을 처리하고 알림을 앱에 전달한다.

https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server

# Establish a Trusted Connection to APNs

내가 대충 서버 만들고 APNs에 야 알림 보내!!!!!!!!!!!!요청을 보내고 싶지만,

알림 요청을 APNs로 보내려면 Provider 서버가 HTTP/2 및 TLS를 사용하여

1. Token(토큰) 기반

2. Certificate(인증서) 기반

둘 중 하나로 신뢰를 설정해야한다.

두 기술 모두 장단점이 있으며 환경에 따라 가장 적합한 기술을 결정하면 된다.

# Establishing a Token-Based Connection to APNs

토큰 기반 인증은 APNs와 stateless한 방법으로 통신하는데,

stateless 통신은 APNs가 Provider서버와 관련된 Certificate or 기타 정보를 조회할 필요가 없기 때문에 Certificate 기반 통신보다 빠르다.

[토큰 기반 인증의 장점]

- 여러 Provider 서버에서 동일한 토큰 사용 가능

- 하나의 토큰을 사용하여 회사의 모든 앱에 대한 Notification을 보낼 수 있음

하지만

매번 요청시 마다 인증 토큰을 요청에 포함시켜야해서 인증서 기반보다 요청이 살짝 크다고 한다.

또한 Apple에서 제공하는 Provider Token Signing Key를 사용하여 한시간에 한번 이상 토큰을 업데이트하고 암호화해야한다고 한다.

이 Signing Key는 개발 및 프로덕션 환경 모두에서 동작하며, Signing Key는 만료되지 않지만 취소할 수 있다.

# Establishing a Certificate-Based Connection to APNs

인증서 기반은, 인증서를 사용하여 Provider와 APNs의 보안연결을 설정한다.

개발자 계정을 통해 이 인증서를 발급받을 수 있다.

토큰 기반과 달리, 신뢰는 서버레벨에서 설정되어있기 때문에 각 요청에는 인증 토큰이 없어도 된다.

하지만,

각 앱에 대해 별도의 인증서를 생성해야하며, 각 앱의 알림에 대해 별도의 APNs연결을 관리해야한다.

(여러 앱을 지원하고자한다면 토큰기반 연결을 사용하는 것이 더 간단하다.)

즉, 토큰 기반 연결의 장점이었던,

하나의 토큰을 사용하여 회사의 모든 앱에 대한 Notification을 보낼 수 있음

는 인증서 기반 연결에서는 간단히 할 수 없다.

또한 매년 인증서를 갱신해야하며 이를 까먹으면 큰 문제가 발생할 수 있다.

(반면에 토큰 기반에서 사용되는 Signing Key는 만료되지 않음)

Provider 서버에서 인증서를 설치했다면, 아래와같은 플로우로 APNs와 연결을 시도하게 된다.

이 과정이 끝나야지 APNs에 알림 요청을 보낼 수 있게 된다.

이렇게 Provider와 APNs사이에 자격 증명들이 전송되기 때문에 (자주 재생성되고 암호화되어있는) 토큰 기반 연결보다 보안이 떨어진다고 아마존 블로그에 나오는데, 정말 상대적으로 보안이 떨어지는거라고 보면될 것 같다.

여기까지 읽었으면 응 토큰쓸거야~ 라는 생각이 들텐데..

맞다.

애플은 각각 장단점이 있다고 했지만.. 내 생각엔 인증서 기반을 쓸 이유가 없는 것 같다. (물론 잘 쓰는 곳도 있겠지만..)

(실제로 토큰 방식 연결이 더 최신이다.)

이제 그놈의 p8과 p12가 각각 어떤것인지 살펴보자.

# p8

p8 포맷은 key이다. 그것도 Token Signing Key이다.

Token Signing Key는 위에서 Token-Based 연결쪽에서 봤는데..

또한 Apple에서 제공하는 Provider Token Signing Key를 사용하여 한시간에 한번 이상 토큰을 업데이트하고 암호화해야한다고 한다.
이 Signing Key는 개발 및 프로덕션 환경 모두에서 동작하며, Signing Key는 만료되지 않지만 취소할 수 있다.

맞다. 이 p8은 Token-based 연결에서 사용되는것이다.