APNs: iOS 디바이스나 Mac 등 애플 디바이스에 Push 알림을 보내는 서비스
APNs에서 제공하는 새로운 인증 방식, API 업데이트에 대해 설명하는 세션.
작년에 (2015년) 발표된 중요한 기능에 대해 리뷰하고 시작하자면,
먼저 HTTP/2 푸시를 기반으로 하는 완전히 새로운 Provider 프로토콜을 도입했다. HTTP/2는 단일 연결을 통해 여러 스트림을 지원하는 프로토콜이며, 속도도 매우 빠르다.
또한 어떤 디바이스 토큰이 더 이상 활성화되지 않았는지 나타내는 즉각적인 피드백 제공을 지원하고,
최대 4KB의 더 큰 페이로드를 전송할 수 있게 되었다.
그리고 인증서 처리를 간소화하여 APNs에 연결하는 데 사용되는 클라이언트 인증서를 줄일 수 있었다.
이 새로운 프로토콜을 통해 초당 수십만 통의 알림을 전송한다.
이제 푸시 알림 전송과 관련된 단계를 살펴보려고 한다.
우측 하단에는 클라이언트 앱이 있고, 우측 상단에는 APNs와 연결하여 푸시 알림을 보내는 서버 구성 요소인 Provider가 있다.
그리고 알림 전송을 시작하기 전에, 개발자 계정에서 Push 알림을 등록해야 한다. 애플리케이션은 좌측 하단의 디바이스에서 실행되는 운영 체제에 등록된다.
디바이스가 APNs에 토큰을 요청한다.
그리고 클라이언트 앱으로 다시 반환한다. 이 디바이스 토큰은 이 디바이스에서 실행 중인 앱에 대해 고유하다.
프로그램에서 이 토큰을 Provider에게 전달해야 한다.
이제 Provider 서비스는 클라이언트 인증서를 사용하여 APNs에 연결한 다음, 표준 HTTP/2 POST Request를 사용하여 해당 디바이스 토큰에 푸시를 보낸다.
HTTP/2 Provider API는 모든 것이 정상이면 성공을 나타내는 즉각적인 response를 제공한다. APNs는 Push 요청을 수신하고 확인했다. 이제 오류가 발생하면 디바이스 토큰이 유효하지 않다는 메세지 또는 400 오류 코드를 반환한다.
예를 들어 "bad device token" (잘못된 디바이스 토큰)과 같은 이유를 알려준다.
만약 디바이스 토큰이 제거된 경우, 410 오류 코드 또는 "removed" 상태를 알려준다. 또한 APNs가 디바이스 토큰이 제거되었음을 마지막으로 학습한 시기를 나타내는 timestamp가 페이로드에 표시된다.
또한 인증서 처리를 간소화 했다.
이제 애플리케이션, 복잡한 구성요소 및 VOIP Push에 대해 하나의 인증서를 제공할 수 있다. 동일한 인증서를 development와 production 환경 모두에서 사용할 수 있다.
이로 인해 많은 개발자들이 여러 인증서를 관리, 갱신 및 폐기하는 과정에서 발생하는 문제를 해결할 수 있게 되었다.
애플리케이션에서 인증서를 관리하는 것이 너무 복잡하다는 걸 본인들도 안다면서.. APNs 인증에 대한 새로운 간단한 방법을 소개하고 있다.
APNs를 위한 토큰 인증 서비스이다. 알림을 보낼 때 클라이언트 인증서 대신 Provider 토큰을 사용하는 방법이다.
인증 토큰은 서비스가 APNs에 연결하는 방법을 간소화하는 것을 목적으로 한다. 또한 프로그래밍 방식으로 쉽게 생성할 수 있기 때문에, 만료되는 인증서를 다시 발급할 필요가 없다.
이는 JSON 웹 토큰을 인증 자격 증명을 생성하는 메커니즘으로 사용해서 활성화할 수 있다.
이제 토큰 인증이 작동하는 방법에 대해 자세히 설명하기 전에, 인증서를 활용한 인증 방법이 어떻게 작동하는지 간략히 요약하고 넘어가려고 한다.
먼저, 개발자 계정에서 클라이언트 인증서를 제공한다.
상호 인증을 사용해서 APNs에 연결할 때, APNs는 신뢰하고 검증할 서버 인증서를 제공한다.
handshake의 일부로, Provider는 클라이언트 인증서를 서명하며, 이 인증서는 APNs가 검증하고 자격 증명을 설정하는 데 사용된다. 이 시점에서, APNs와 Provider 간에 신뢰할 수 있는 연결이 설정된다.
이 연결을 통해 보내는 모든 푸시는 클라이언트 인증서로 식별된 애플리케이션에 연결된다.
요약하자면, 인증서 인증 방식을 사용하는 경우,
개발자 계정에서 client certificate를 제공하고,
APNs에서는 server certificate를 제공하여 인증을 수행한다.
이후에는 provider가 client certificate를 서명하고,
APNs가 이를 인증하여 credential을 설정한다.
이제 APNs에서 토큰 인증 방식을 사용하는 방법에 대해 소개한다.
client certificate 대신 JSOn Web Token(JWT)인 provider token을 사용하여 인증하는 방식이다.
토큰 인증을 사용할 때는 계정에서 토큰 로그인 키를 선택해야 한다.
그러면 provider는 client certificate 없이 PLS (Provider to APNs) 연결을 설정한다.
하지만 이 연결에 대한 알림을 보내기 전에, Provider는 사용자의 Team ID를 포함하는 인증 토큰을 구성한다. 그런 다음 key opt indicator를 사용하여 서명한다.
이제 이 연결을 통해 푸시 알림을 보낼 수 있다.
서명된 모든 알림 메시지에는 인증 토큰이 포함되어야 한다.
APNs는 먼저 토큰을 사용하여 provider를 인증한 다음 요청을 처리한다. 이 요청이 성공적으로 처리되면 APNs는 성공을 나타내는 응답을 다시 보낸다. 요청에 제공된 토큰이 없거나, 토큰이 올바르지 않은 경우, 오류를 나타내는 응답이 다시 전송된다.
(APNs는 오류가 발생해도 연결을 닫지 않음)
이제 Provider 토큰을 생성하는 방법에 대해 살펴보려고 한다.
개발자 계정의 Certificate, ID 및 Profile 섹션에서 로그인 키를 프로비저닝 하는 것부터 시작해야 한다. (공개키, 개인 키쌍이 생성된다.) 그런 다음 개인 키는 토큰 데이터를 암호화 하는데 사용할 수 있다.
그리고 그 개인키에 대응하는 공개키를 사용하여 토큰의 유효성을 검사한다. 이제 토큰을 구성하는 방법을 살펴보면,
맨 위에는 요청의 일부인 JSON 웹 토큰이 어떻게 생겼는지를 보여준다.
이 JSON 웹 토큰의 구조를 살펴보면, 3가지 부분으로 구성되어 있다. 각 부분은 마침표로 구분되는 base-64 인코딩 문자열이다.
그 아래 부분은 이 웹 토큰의 디코딩된 표현인데, 첫 번째 부분은 header이다.
header에는 토큰 서명에 사용되는 알고리즘을 지정하는 속성도 포함된다. 이 경우 ES256이다.
또한 토큰에 서명하는 데 사용되는 키의 식별자도 포함된다.
claims 섹션에는 계정에서 얻을 수 있는 개발자 Team ID인 확인자 트리뷰트가 포함된다. 그리고 두 번째 속성은 초로 표현되는 초기 타임스탬프이다.
토큰의 마지막 부분은 header와 claims에 서명 알고리즘을 적용하여 얻은 base-64 서명이다.
이 서명을 통해 토큰이 생성된 후 무단으로 변경되는 것을 방지할 수 있다.
다음은 HTTP/2가 토큰 인증을 사용하여 request를 작성하는 내용이다.
이 요청에는 header와 data 프레임이 포함되어 있다. header는 apns-topic을 포함한 다양한 헤더 필드로 구성된다.
이제 헤더 프레임에 "bearer" 값과, 서명된 provider 토큰이 있는 권한부여(authorization) 헤더가 포함된다.
인증 토큰을 포함한 요청이 유효한 경우, 응답은 200 또는 "OK"가 된다. provider 토큰이 유효하지 않은 경우, 응답 내용은 다음과 같다.
403 또는 "Forbidden"이다.
APNs는 새 토큰을 주기적으로 생성해야 한다. 토큰이 너무 오래된 경우, 응답은 토큰이 만료되었음을 나타내는 이유와 함께 다시 403 "Forbidden"오류가 뜬다.
하지만 모든 요청에 대해 새 토큰이 생성되어서는 안된다. 성능을 위해 토큰이 유효한 한 재사용하는 것이 좋다.
요약하자면,
provider 토큰은 주기적으로 생성되어야 한다. (유효기간을 1시간으로 설정되어 있으며, 이 기간이 지나면 새로운 Signed Token을 생성해야 함)
하지만 로그인 키는 만료되지 않는다.
로그인 키가 손상된 것으로 의심되는 경우, 계정에서 키를 해지하고 새 키를 프로비저닝 할 수 있다. APNs는 인증을 계속 지원한다. 이것이 토큰 인증이다. 올해 (2016년)에 출시될 예정..
