APNs 를 통한 Push 알림 이해하기

오늘은 개개인이 갖고 있는 아이폰 디바이스에 푸시 알림이 오는 과정에 대해 알아보려고 합니다.
앱 개발자의 관점에서 살펴봅니다 :)

먼저 푸시가 전송되는 큰 흐름을 간략하게 보고 블라인드로 남아있는 부분을 하나씩 알아보겠습니다.

 

흐름 이해하기

개별 디바이스에 직접적으로 푸시 알림을 보낼 수 있는 주체는 오직 APNs 뿐입니다.
APNs 란 Apple Push Notification server 의 약자로 즉 애플만이 직접적으로 디바이스에 푸시 알림을 보낼 수 있습니다.

 

따라서 저희는 APNs 에게 우리 앱에 푸시를 보내줘! 라고 요청해야 합니다.
이 요청이 유효한지 보고 APNs 가 푸시를 보낼지 말지를 판단합니다.

이 요청 또한 정해진 규격에 맞게 APNs 와 연결한 후에 가능하고, 이를 위해 APNs 에게 요청해줄 저희의 서버가 필요합니다.
문서에서 이를 Provider Server 라고 칭하는데 여기선 간략하게 저희 '서버' 정도로 칭하도록 하겠습니다.

그렇담 APNs 에서는 뭘 보고 보내도 될지 판단할 수 있을까요?
당연히 사전에 앱에서 저희 서버에게 필요한 정보들을 알려줘야 합니다.

네 이게 매우 많이 후려친(?) 큰 흐름입니다. 먼저 전체적인 흐름을 한번 생각 해봤습니다.
앱에선 4번을 받기 위한 작업도 필요하지만, 이건 크게 어렵지도 않고 다른 자료들도 많이 있으니 여기선 다루지 않겠습니다.
오늘 저희의 관심사는 1, 2, 3 입니다. 이제 필요한 건 뭔지, 어떻게 보내고 검증하는지를 더 살펴보겠습니다.

 

APNs 에 보내려면

APNs 에 요청하려면 다음 정보들이 필요합니다.

• JSON payload -> 문서 & 서버🙏
• Device Token -> ?
• 스펙이 정의된 Request Header -> 문서 & 서버🙏
• (토큰 기반일 때만, 이하 Auth Token) Authentication Token -> ?

 

JSON payload, request header 는 서버에서 처리해주실테고,, 문서에 잘 나와있으니
저희는 JSON 형태의 뭔가가 있고 header 정의해야 하는구나! 정도로 넘어가면 알고 될 거 같습니다.

 

남는 의문.

1. Device Token 이 뭐지? 어떻게 얻지?

2. 토큰 기반은 뭐지? 그럼 다른 건?

3. Auth Token 이 뭐지? 어떻게 얻지?

 

Device Token

APNs 가 기기에 푸시를 제대로 보내기 위한 고유 주소 역할을 합니다.
기기와 앱 모두 고유한 주소를 갖습니다.
당연히 두 앱이 같은 기기에 설치되어 있더라도 한 앱의 토큰은 다른 앱에서 쓸 수 없습니다.

앱이 시작되면 APNs 에 요청해 Device Token을 얻을 수 있고
이걸 우리 서버에 보내 저장하고 있도록 합니다.
참고로 이 Device Token 은 앱이 백업될 때 새로 발급되니 절대 로컬에 캐싱해두지 말라고 하네요.
(백업은 사용자가 앱을 다른 다비이스에 설치하거나, os를 재설치 하는 경우 등을 얘기하는 것 같습니다.)

Deivce Token은
UIApplication의 registerForRemoteNotifications() 메서드로 요청하고 올바르게 자격 인증이 되어있다면,
App Delegate의 application(_:didRegisterForRemoteNotificationsWithDeviceToken:) 메소드로 받을 수 있습니다.

(저 사전 자격 인증도 알아봐야 하는데요, 내용이 자꾸 길어지니 이건 따로 다뤄보도록 하겠습니다. 아무튼 유료 계정이 필요합니다.. ㅠ)

 

두 가지 인증방법

앞서 필수 정보에서 payload, request header, device token 등은 어떻게 푸시를 보낼지에 대한 정보에 가까웠다면,
이제는 어떻게 검증할지에 대해 알아봐야 할 차례입니다.

토큰 기반과 증명서 기반, 두 가지 방식으로 인증이 가능합니다.

 

Certificate-Based Connection

증명서 기반의 연결은 서버가 APNs 와 연결할 때 증명서를 통해 보안 연결하는 방식입니다.
서버레벨에서 인증되기 때문에 노티 요청에서 별도의 인증 토큰은 필요하지 않습니다.
인증 토큰이 없기 때문에 개별 요청의 크기도 토큰 기반에 비해 약간 작습니다.

다수의 앱에 노티를 보내기 위해서 각각의 앱마다 개별 증명서가 필요하고, 앱 별로 개별 보안 연결 관리가 필요합니다.
결과적으로는 토큰 기반이 더 관리가 쉽습니다.

Token-Based Connection

토큰 기반 인증의 경우엔 앞서 얘기 나온 대로, 요청을 보낼 때 Auth Token 이 필요합니다. 
보낼 때 토큰을 함께 보내니 stateless 하게 APNs와 통신할 수 있는데요, APNs 가 증명서를 찾을 필요도 없고 서버의 다른 정보도 필요 없으니 보다 빠르게 통신할 수 있습니다.
개별 요청에 인증 토큰이 포함되니 증명서 인증 방식 보다는 요청의 크기가 약간 큽니다.

토큰 방식은 여러 서버에서 같은 토큰을 사용할 수 있고,
하나의 토큰으로 사내 여러 앱에 사용할 수 있습니다.

애플이 제공한 공급자 서명키로 최소 한 시간에 한 번 이상 암호화해 업데이트가 필요합니다.

공급자 서명키를 만들면
10 글자의 Key ID 와 텍스트 파일로 된 p8 확장자 키를 받습니다. 
Key ID는 JSON Payload 에 포함되어야 합니다.

따라서 사전에 서버에 Key ID와 p8 키가 모두 등록되어있어야 하겠죠?
키는 한 번 발급받으면 다시 재발급 받을 수 없으니 잘 관리해야 합니다 :)
잃어버리면 revoke 하고 새로 발급받아야 함.

 

---

정리하면

애플(APNs) 만이 디바이스에 푸시를 보낼 수 있음.

APNs 푸시 쏴달라고 요쳥할 서버가 필요함.

요청에는 푸시를 보낼 때 필수적으로 필요한 3가지 정보가 필요함.
ㄴ JSON Payload, Request Header, Device Token

인증도 필요한데 2가지 방법이 있음. 토큰 기반, 증명서 기반.
ㄴ 증명서 기반은 서버 연결시 인증하는 방법, 서버 레벨에서 인증이 되었기 때문에 요청에 별도의 인증 토큰은 필요 없음.
요청에 토큰 정보가 없으니 크기가 약간 적지만, 앱 마다 개별 증명서가 필요하고 이걸로 개별적으로 보안 연결해서 관리해야함.
ㄴ 토큰 기반은, 요청 보낼 때 토큰 정보를 보내는 방법. APNs 가 증명서를 확인할 필요도 없고, 서버의 다른 정보도 필요치 않으니 stateless 하게 통신 가능하고 빠름. 대신 토큰이 들어가니 요청 크기가 약간 증가함.
서버는 한 시간에 한 번 이상 p8 인증키로 암호화해서 업데이트 시켜줘야함.

 

이렇게 APNs 를 통해 원격 푸시 알림을 보내는 과정에 대해 알아봤습니다.
저는 그 동안 항상 머리 속에 그림이 잘 안 그려지고 두리뭉술 하게만 알고 있었는데, 이번에 정리하면서 많은 의문이 해소되었습니다.

다른 분들에게도 도움이되었으면 좋겠네요.
읽어주셔서 감사합니다.

 

참고

Sending Notification Requests to APNs

Establishing a Certificate-Based Connection to APNs

Establishing a Token-Based Connection to APNs

Registering Your App with APNs