🔐 Apple 로그인 A to Z: 로그인, 인증, 그리고 탈퇴 처리

App Review Guidelines - Apple Developer
Sign in With Apple Overview
Revoke tokens | Apple Developer
Sign in with Apple - Human Interface Guidelines

이번 글에서는 Flutter에서 Apple 로그인에 대한 모든 것을 자세히 알아보도록 하겠다.

iOS 앱을 배포할 때, 로그인 방식으로 소셜 로그인을 제공하게 되면 무조건 Apple 로그인을 제공해야 한다. 애플의 정책이다.

수많은 앱을 배포 해봤지만 여전히 가장 억지스러운 정책이라 생각하는 것이 바로 Apple Login 의무화다..

경험상 지금까지 배포한 서비스들의 소셜 로그인 비율을 보면 국내는 거의 카카오고, 글로벌에서는 단연 구글이 압도적으로 비중이 높았기 때문에, 로그인 개발시 애플 로그인은 매우 귀찮은 작업일 수 밖에 없다.

하지만 배포를 위해서는 개발자로서 정책도 지켜야하니 Apple Login을 사용한 로그인과 인증 절차 및 탈퇴시 가이드라인에 따른 연동 해제 절차까지 정리해 보도록 하겠다.

*소셜 로그인을 제공하지 않는다면, Apple 로그인을 의무로 제공할 필요는 없음.

Understanding Apple Login Process

Apple 로그인 진행 전 반드시 필요한 준비물이 하나 있다. 바로 Apple Developer Program 멤버십 계정이 필요하다. 즉 애플 개발자 계정이 있어야 한다.

만일 개발자 계정이 없는 상태라면, 진행이 불가능하다.

지속적으로 iOS나 Apple 관련 어플리케이션을 배포할 예정이라면 당연히 멤버십 구독이 필요 하겠지만, 단순 학습용으로 사용한다면 당장의 멤버십 구독을 추천하지는 않고 필요할 때에 구독을 해서 사용해 보는 것을 추천드린다. 매년 129,000원을 지불해야 하기 때문에 결코 적은 돈은 아니며, 중간에 구독을 중단하게 되면 배포된 앱은 모두 취소된다.

본격적으로 Apple 로그인을 진행하기 앞서 필요한 절차들에 대해서 살펴보도록 하자.

먼저 각자의 인증, 백엔드, Serverless 등의 환경들이 다르기 때문에 설정 방법 및 사용 방법도 일부 다를 수 있는데 최대한 모든 경우에 대해서 다뤄볼 예정이다.

참고로 Firebase나 백엔드 없이도 Apple Login을 구축하는 것은 가능하다.

Apple 로그인은 OAuth 2.0 기반의 인증 방식을 사용하고 있다. iOS, Mac OS, Web 등에서 사용할 수 있고, Android 또한 제한적으로 사용이 가능하다.

아래에서 자세히 다뤄보겠지만 Apple 로그인시에 반드시 고려해야 하는 부분 중에 하나가 Private Relay Email, 사용자 정보 및 토큰 무효화에 관한 내용 이다.
사용자가 실제 이메일을 공유하기를 원하지 않는다면 실제 이메일 주소는 확인할 방법이 없고, 사용자 정보에 대한 제공도 최초 로그인시에만 제공되고 이 후 로그인시에는 NULL을 반환하기 때문에 이 부분을 고려해서 설계하여야 한다.

토큰 무효화는 Apple의 정책이기 때문에 필수로 구현해야 하는 기능이다.

App Store Review Guidelines - 5.1.1 (v) Sign in with Apple
Apps that use Sign in with Apple must also support account deletion initiated from within the app.

Apple Login 절차는 아래와 같은 순서로 진행해 주면된다.

1. Apple 로그인 표시
2. 인증 및 ID 토큰 발급
3. Identity Token 검증
4. 사용자 정보 제공
5. 회원 탈퇴시 Apple 계정 연결 해제

각 단계별 방법 및 설명에 대해서는 아래에서 자세히 다뤄보도록 하겠다.

Configuring Apple Sign-In

Apple 로그인을 위한 사전 설정을 진행해주자.

Apple Developer > Certificates, Identifiers & Profiles에 접속하도록 하자.

개발자 계정과 관련된 기능은 Apple Developer에서 제공하고 있고, 앱과 관련된 기능은 Store Connect 에서 제공하고 있다.

디벨로퍼에서는 앱의 식별자에 Sign in with Apple 기능을 활성화하고 필요에 따라 키를 등록하는 절차를 진행해주면 된다.

먼저 식별자를 아직 등록하지 않은 경우라면 Identifiers 탭으로 이동해서 추가를 해주시면 된다.

Apple Developer에 처음 방문하신 분들도 계실 수 있으니 최대한 자세하게 설명하도록 하겠다. 기존 식별자를 사용하는 분들은 아래에 "Sign in with Apple" 활성화 단계부터 진행하시면 된다.

식별자를 추가할 때에 여러가지 식별자가 있는데, 앱만 타겟할 것이기 때문에 App IDs로 진행을 하자.

App과 App Clip 두 가지를 선택할 수 있는데, 간단하게 설명하면 App은 일반적으로 App Store를 통해서 제공하는 완전한 애플리케이션이고 App Clip은 사용자가 App Store에서 전체 앱을 설치하지 않아도 특정 기능을 빠르게 제공하기 위한 경량화된 미니 앱이라고 보시면 된다.
기회가 된다면 App Clip에 대해서 추후에 다뤄봐도 좋을 것 같다.

App 타입을 선택해주도록 하자.

Bundle ID를 입력해 주면 되는데, Bundle ID는 프로젝트의 XCode를 열면 Bundle Identifier에서 확인할 수 있다.

만일 개발자 계정에 여러 앱을 배포할 계획이라면 Description 필드에 확실한 정보를 기입하여야 한다.
여러 앱을 배포하게 되더라도 개발자 계정이 한 개라면 모든 식별자가 해당 탭에서 관리되기 때문에, 식별자 관리를 위해서 적절한 네이밍을 넣어야 관리가 수월해 진다.
이전에 다른 식별자를 삭제하는 바람에 곤혹을 치뤘던 경험이 있었다...

단 하나의 앱만 배포할 경우라면 그냥 프로젝트명을 넣어주는게 일반적이다.

식별자에 Sign in with Apple 기능을 활성화 해주자 !

기존 식별자를 사용하시는 분들은 식별자를 탭하면 편집을 할 수 있다.

Capabilities 탭에서 아래로 스크롤하여 Sign in with Apple을 선택해 주도록 하자.

이제 Apple 로그인이 활성화 된것이다.

---

(Optional) Edit Sign in with Apple

Edit 버튼이 보이는데, Edit과 관련되서는 필수 항목은 아니니 필요에 따라 절차를 진행하시면 된다.

Sign in with Apple: App ID Configuration

App ID에 관련된 추가 기능을 제공하는 영역으로, 여러 플랫폼에서 인증 정보를 공유하고자 할 때 유용하게 사용할 수 있다.

Primary App ID란 여러 플랫폼 간의 인증 정보를 공유할 수 있도록 지원하는 앱 그룹의 주요 ID 역할을 한다.
사용자가 한 번 동의하면, 그룹 내 모든 앱에서 Sign in with Apple 인증 정보를 공유할 수 있다.

이해가 잘 안 되시는 분들은 iOS 개발 시 사용하는 App Groups에 대해 알아보시면 금방 이해할 수 있을 것이다.
App Group은 여러 앱 간에 데이터를 공유할 수 있도록 설정하는 기능으로, Primary App ID는 인증 정보를 공유한다는 점에서 유사하다.

기본적으로 선택된 옵션은 현재 등록 중인 App ID를 새로운 Primary App ID로 설정하는 것이다.
만약 "Group with an existing ..." 옵션을 선택하면, 기존에 등록된 Primary App ID에 그룹화되어 동일한 인증 정보를 사용할 수 있다.

Server-to-Server Notification Endpoint

해당 섹션은 백엔드 환경이나 Firebase Authentication 등의 인증 서비스를 사용하는 경우에만 설정할 수 있다.

Apple이 앱에서 중요한 계정 관련 변경 사항을 감지하면 해당 URL로 알림을 보내주는 기능인데, 등록한 URL은 Apple이 서버 요청을 전송할 웹훅(Webhook)의 엔드포인트 역할을 하게 된다.

알림이 발생하는 주요 이벤트로는 Apple ID와 앱의 연결을 해제한 경우(Revoke), Apple ID가 삭제된 경우, Private Relay Email이 변경된 경우이다.

설정 URL은 반드시 HTTPS를 사용해야 하며, TLS 1.2 이상을 지원해야 한다.
자세한 내용은 공식문서를 참고하세요.

---

마지막으로 입력한 정보를 확인 후 생성해주면 식별자가 추가된 것을 확인할 수 있다.

Flavors 등의 빌드 변형을 구축한 환경이라면 변형된 식별자를 추가로 해당 Identifiers에 추가해주면 모든 환경에서 원활히 Apple Login을 사용할 수 있다.

Firebase Authentication

Firebase 프로젝트 생성부터 연동까지...

Firebase Authentication을 사용하는 분들은 추가적인 절차가 필요하다.

우선 Firebase 연동이 되어있지 않다면 연동 후에 절차를 수행하시면 된다.

Authentication을 선택한 후에 로그인 방법 탭으로 이동하여 새 제공업체를 추가해주자. 제공처로 Apple을 선택해 활성화 해주도록 하자.

상단에 사용설정을 활성화하고 하단에 도메인을 복사해서 저장을 눌러주자.

여기서 하단에 생성된 도메인이 바로 위에서 살펴본 Server-to-Server Notification Endpoint의 URL이 된다.

위에서도 설명 했듯이 필수 사항은 아니고, 해당 도메인을 Apple Developer에 등록하지 않아도 Apple Login 기능 자체를 사용하는데는 문제가 없지만 계정 변화에 대한 알림 구독을 받지 못하니 추가하는 것을 권장한다.

Identifiers 탭에서 생성한 식별자를 선택 후 활성화한 Sign in with Apple 기능의 Edit으로 접근하면 해당 도메인을 넣어 줄 수 있다.

Apple Login 기능을 사용하기 위해 여러 블로그나 관련 도큐먼트를 보신 분들 중에서는 나와있는 내용마다 일부 설정을 다르게 설명하고 있어 헷갈리신 부분들이 있을 겁니다.

설정이 조금씩 다른 이유는 아마도 Android나 Web에 필요한 설정이 추가로 필요하거나 해서 그런겁니다.
Firebase Authentication 설정과 관련해서도 어떤 ID로 식별자를 생성하였고, 어떤 서버 환경을 구축해서 사용 하는지에 따라서 조금씩 설정이 다르게 되는 것이다.

만일 iOS에서만 Apple Login 기능을 사용 하신다면 여기까지 설정하시면 되고, 나머지 설정들은 불필요한 설정이 될 수도 있습니다.
필요 없는 설정들이 추가되어 있어도 기능을 사용하고 운영하는데는 전혀 문제가 없는 것도 맞지만 시간이 흐름에 따라 여러 개발자의 손을 타면서 운영이 되다보면 유지보수는 점점 어려워지기 마련이라 최대한 필요한 부분만 설정할 수 있도록 하는 편입니다.

그래도 궁금하신 부분들이 있으니 몇 가지 설정에 대해서 간단한게만 살펴보도록 하겠습니다.

먼저 App IDs와 Services IDs를 어떤 타입에서 사용해야 하는지에 대해서 알아보면, App ID는 일반적으로 iOS의 네이티브 앱에서 사용하는 고유 식별자라고 생각하시면 됩니다. 반면 Services ID는 웹 서비스와 통합이 필요하거나 OAuth 기반의 인증 흐름을 구현하고 앱과 웹간의 리다이렉션을 처리하기 위한 Apple 로그인을 구현할 때에 사용할 수 있는 식별자 입니다.

Apple Login에서는 Android에서 OAuth 기반의 인증을 구현하고자 한다면 Services ID를 사용할 수 있습니다.

그 다음은 Key를 생성하는 부분인데, Apple과의 보안 통신을 위해 사용하는 암호화 키를 생성하는 것으로, Apple Login에서는 인증 및 JWT 서명이 필요한 경우에 생성하여 사용할 수 있다.

Implementing Apple Sign-In

이제 Flutter 코드를 사용해 애플 로그인을 구현해 보도록 하자.

먼저 Apple Login을 플랫폼 채널을 통해 네이티브로 직접 구현할 수 있지만, 여기서는 패키지를 사용해 간단하게 처리해 주도록 하겠다.

Add dependencies

dependencies:
	sign_in_with_apple: ^6.1.4

Firebase 사용시 firebase_auth 패키지를 추가하도록 하자.

Sign in with Apple

Apple 로그인을 위한 Developer 설정에 이이서 XCode에서도 Sign in with Apple 기능을 활성화 해주자.

Signing & Capabilities 탭으로 이동하여 Capabilities 추가를 눌러 Sign in with Apple을 추가해주면 된다.

iOS 개발에 관련해서 익숙하지 않으신 분들은 저걸 왜 추가하는지 궁금하실 수도 있다. 추가하면 그냥 목록에만 추가되지 다른 기능이 있거나 그렇지 않기 때문일 것이다.

Capabilities는 주로 Apple의 시스템과 관련된 기능들의 활성화가 필요할 때 추가하게 되는 것으로 해당 기능이 활성화 되지 않은 상태로 배포가 이뤄지면 기능이 정상적으로 작동하지 않는다.

Apple 시스템(여기서는 iOS) API는 앱의 Capabilities 설정을 바탕으로 시스템의 기능을 활성화하기 때문에 XCode에서도 Capabilities 추가가 반드시 필요한 것이다.

대표적인 Capabilities 기능들로는 우리가 잘 알고 있는 시스템 API인 Notifications, Apple Pay, iCloud, HealthKit, App Groups 등이 있다.

애플 로그인 사용시에는 까다로운 애플의 디자인 정책을 준수하여야 한다. 당연히 준수하지 않고 제멋대로 UI를 반영하게 되면 Apple 심사 거절 가능성이 높다.

Sign in with Apple - Human Interface Guidelines 기준을 확인한 후 UI에 반영하여 로그인 버튼을 만들도록 하자.

아래 코드를 입력하면 애플 로그인을 요청하게 된다. scopes 파라미터는 필수 값으로 원하는 데이터를 추가해서 요청할 수 있는데, 원하는 데이터가 없다면 빈 배열로 요청해도 상관 없다.

await SignInWithApple.getAppleIDCredential(scopes: [
	// AppleIDAuthorizationScopes.email,
	// AppleIDAuthorizationScopes.fullName,
]);

None	[ email ]	[ fullName ]	[ email, fullName ]

애플 로그인으로 제공 받을 수 있는 데이터는 email, fullName 이게 끝이다...

정책상 개인정보를 엄격하게 관리하기 때문에 제한적으로 데이터를 제공 받을 수 있는데, Email인 경우는 심지어 Hide My Email(이메일 가리기) 옵션을 선택할 수 있어 실제 이메일 주소가 아닌 가상 이메일 주소를 얻게 될 수도 있다.

대부분의 소셜 제공업체가 기본적으로 제공하는 프로필 이미지 조차 가져올 수가 없다.

애플 로그인이 다른 소셜 로그인에 비해 까다로운 부분 중에 하나는 바로 최초 로그인 요청시에 한 번만 email, fullName등의 데이터를 제공 한다는 것이다..

최초 한 번만 데이터를 제공한 후 부터는 null을 반환한다. 정말 null을 반환하는지 credential을 출력해 보도록 하자.

최초 요청시에는 이름과 메일정보를 정상적으로 반환하지만 그 이 후부터는 null로만 반환하는 것을 확인할 수 있다.

실제로 애플로그인 화면에서도 최초 로그인과 이 후 로그인의 화면도 다르게 나타난다.

어떻게 사용자를 식별할 수 있을까 ? 애플은 사용자 고유 식별자로 userIdentifier를 제공하고 있어서 userIdentifier를 활용하여 내부적으로 사용자 검증에 사용하면 된다.

Email Options

애플이 제공하는 Email에 대해서 좀 더 자세히 알아보자.

애플 로그인시에 선택할 수 있는 옵션은 Share My Email, Hide My Email 이렇게 2가지 옵션이 있다.

Share My Email(이메일 공유)은 실제 이메일 주소로 로그인하여 일반적인 소셜 로그인과 다른게 없지만 Hide My Email(이메일 가리기)은 가상의 이메일 주소인 것이다.

이메일과 관련된 옵션은 개발자들이 선택적으로 요청할 수 없게 되있으며, 앱 사용에 있어서 이메일 가리기를 선택한 사용자를 앱 내에서 진입을 허용하지 않거나 의무적으로 실제 이메일을 입력하도록 해서는 안된다고 한다 (아마도 리젝 사유인 듯...).

Hide My Email 옵션으로 로그인한 사용자에 한해서 애플은 가상 이메일 주소로 Private Reley Email을 생성해 제공하게 된다.

Private Reley Email은 앱마다 고유하게 생성이 되고, 해당 이메일로 메일을 보내면, 실제 사용자의 이메일 주소로 메일을 전송해주는 Forwarding 기능을 제공해주고 있다.

하지만, 개발자가 고려해야 하는 몇 가지 사안도 있는데 바로 로그인한 사용자가 수동으로 메일의 연결을 해제할 수 있기 때문에 항시 이메일 외의 연결 수단을 만들어야 한다는 것이다. 만일 수동으로 연결을 해제하지만 않는다면 영구적으로 만료되지 않고 사용이 가능하다.

*Private Reley Email과 관련해서는 추후 자세한 내용으로 작성해 보도록 하겠다.

Authentication

앱에서 정상적으로 애플 로그인이 수행되고 나면, 각 환경에 따른 다음 스텝을 진행해 주면 된다.
일반적으로 애플 로그인과 같은 소셜 로그인은 하나의 인증 수단일 뿐이기 때문에, 고유 ID를 사용해 앱 내부에서 별도로 인증을 진행하게 될 것인데, 해당 절차는 현재 서비스의 내부 절차대로 해주면 된다.

추가적으로 서버에서 Apple ID 대한 검증을 거쳐야 한다면, 앱에서 로그인 성공 후 반환되는 데이터 중 authorizationCode, identityToken을 서버에 전달하여 애플로 부터 토큰 검증을 요청 하는 등의 절차를 수행할 수 있다.

Authorization Exception

sign_in_with_apple 패키지 사용시 예외 처리에 대해서 간단하게 살펴보자.

Exception 처리시 SignInWithAppleAuthorizationException을 캐치해서 에러를 확인할 수 있다. AuthorizationErrorCode를 반환하는데, 예외 타입은 6가지가 있다.

enum AuthorizationErrorCode {
	canceled, failed, invalidResponse, notHandled, notInteractive, unknown
}

예외 케이스에 대한 설명은 해당 패키지 파일을 참고하시면 된다.

Firebase Authentication

Firebase Authentication에서 사용하는 소셜 로그인 인증 방식과 동일하게 애플 로그인을 연결하고 관리할 수 있다.

애플 로그인 인증 성공시 반환되는 identityToken
과 authorizationCode를 Authentication의 OAuthProvider로 전송해 사용자 인증을 마무리 할 수 있다. 이 때, provider로 apple.com을 사용해 주면 된다.

final OAuthCredential authCredential = OAuthProvider("apple.com").credential(
        idToken: credential.identityToken,
        accessToken: credential.authorizationCode,
);

생성된 OAuthCredential으로 로그인을 요청해 UserCredential을 정상적으로 생성할 수 있다.

final UserCredential user = await FirebaseAuth.instance.signInWithCredential(authCredential);

Code

Future<void> signInWithApple() async {
    try {
      final AuthorizationCredentialAppleID credential =
          await SignInWithApple.getAppleIDCredential(scopes: [
        AppleIDAuthorizationScopes.email,
        AppleIDAuthorizationScopes.fullName,
      ]);
      
      print(credential.userIdentifier);

	  // [Optional] Firebase Authentication 연동 시 절차
      final OAuthCredential authCredential = OAuthProvider("apple.com").credential(
        idToken: credential.identityToken,
        accessToken: credential.authorizationCode,
      );
      final UserCredential user =
          await FirebaseAuth.instance.signInWithCredential(authCredential);

	} on SignInWithAppleAuthorizationException catch (e) {
      // Handling errors on failure
    } catch (_) {
      // Handling other errors
    }
  }

Revoking Apple Login Tokens

Sign in with Apple 기능을 제공하기 위한 디벨로퍼 세팅, 애플 로그인 요청, 마지막으로 사용자 인증까지 완료를 했다.

과연 모든 절차가 끝난걸까 ?

아니다. Apple 로그인을 요청하는 것 만큼이나 중요한 작업이 남아있다. 바로 토큰 무효화(Revoke Token)기능이다.

사실 애플 로그인과 관련해서는 관련 내용이나 정보를 쉽게 찾아볼 수 있고, 이미 많은 개발자 분들이 상세하게 글을 작성해주셔서 별도로 글을 작성할 계획은 없었었다. 하지만 몇 년만에 신규 서비스 출시 기회가 있어서 애플 로그인 작업을 진행하게 되었는데, 오랜만에 해보니깐 기억도 잘 안나고 그래서 이참에 세세하게 정리를 해야겠다는 마음이 생겨서 글을 작성하게 된 것이었다.

세세하게 정리가 필요했던 기능 중 하나가 바로 토큰 무효화(Revoke Token) 기능인데, 이 기능은 서버 환경을 갖춘 서비스에서는 클라이언트 입장으로는 크게 고민할 필요가 없는 기능이긴 하다. 만일 애플 로그인을 제공하는 서비스인데 토큰 무효화에 대해서 잘 모르신다면 아마도 운영하는 서비스의 백엔드에서 처리하고 있을 가능성이 높다.

애플에서는 서버에서 수행하도록 하는 요청인데, 1인 개발 또는 Serverless 환경에서 운영을 하게 되는 경우에는 어쩔 수 없이 결국 클라이언트에서 해결해 주어야하기 때문에 클라이언트에서 토큰 무효화(Revoke Token)를 어떻게 요청하고 처리해야 하는지 알아보도록 하겠다.

토큰 무효화(Revoke Token)란 무엇일까? 사실 별거 없다. 서비스와 애플 계정 간의 연결을 해제해 주는 기능이다.

애플에서만 수행해야 하는 기능은 아니고 모든 소셜 로그인 업체가 요구하는 기능이다.

회원 탈퇴시나 계정을 비활성화할 경우 사용자 정보를 지우거나 비활성 처리를 하게 되더라도 소셜 로그인과의 연결이 끊어지는 것은 아니다. 각 소셜 로그인의 연결된 계정을 살펴보면 내가 탈퇴한 서비스가 아직도 제공된 서비스로 뜨는 경우가 많은데, 내 계정간의 연결을 해당 서비스에서 해제를 요청하지 않았기 때문에 여전히 연결된 상태로 남아있는 것이다.

위에서 설명한 것과 같이 애플 로그인은 최초 연결시에만 email, fullName 정보를 반화하기 때문에 만일 탈퇴한 사용자가 재 가입을 진행하게 되었을 때에도 연결이 끊어져 있지 않다면, 이러한 정보를 가져올 수 없다.
개인정보가 중요한 만큼, 정상적으로 연결을 해제하여 안전하게 처리하도록 하자.

토큰 무효화(Revoke Token)를 수행하는 절차에 대해서 먼저 설명하겠다.

1. 애플 로그인으로 authorizationCode 확인
2. JWT(Client Secret) 생성
3, AccessToken or RefreshToken 발급
4. Revoke 요청

절차를 보면 많이 복잡해 보이지는 않는데, 해야할 작업이 생각보다는 많습니다.. 잘 따라하셔서 모두 잘 구현하시길 바랍니다.

JWT(Client Secret) 생성을 위해서는 암호화된 프라이빗 키를 발급받아 토큰 생성시 인증을 진행해 주어야 하기 때문에, 우선 키를 발급받도록 하자.

Developer에 Keys 탭에서 생성을 진행해 주면 되는데, 만약에 Sign in with Apple 기능을 사용하고 있는 서비스로 키를 이미 발급받은 상태라면 기존 키를 사용하셔야 한다.

Key 발급 후 단 한번만 다운로드 가능함 - 잘 보관해야 함.

Key Name과 Description을 작성해주자. 운영중인 서비스의 키는 삭제되면 복잡한 문제가 발생하기 때문에 반드시 Key 관리는 신중하게 해주어야 한다. 네이밍은 일반적으로 서비스명을 넣어준다.

하단에 Sign in with Apple 기능을 체크하고 Configure를 눌러주자.

기존 키를 사용하시는 경우에는 기존 키를 선택해 절차를 수행하시면 된다.

서비스하는 앱을 선택해 저장하고 발급 정보가 맞으면 Register를 눌러 키를 생성해주자.

여기서 Download 버튼이 활성화 되면 다운로드 하자.

다운로드는 단 한번만 가능하니, 다운받은 .p8 파일은 잃어버리지 않게 잘 보관해 주자.

* 테스트 또는 아직 키를 사용하지 않았다면 언제든지 삭제 후 재발급 받을 수 있음.

앞서 정리한 플로우대로 진행을 해보면 토큰 무효화를 위해 해결 해야할 부분이 authorizationCode를 가져오는 부분하고, JWT를 생성하는 부분일 것이다.

아마도 기억나지 않을 수도 있겠지만, authorizationCode를 가져오는 부분은 우리가 이미 진행한 내용이었다. 바로 애플 로그인을 통해서 얻을 수 있기 때문이다.

OAuth 2.0 인증 프로세스에서 Token을 발급 받기 위한 일회성 코드가 authorizationCode 이다. 해당 코드는 만료 시간이 짧고, 일회성 코드이기 때문에 별도로 보관한다고 해도 의미가 없다.

이러한 문제로 인하여 회원 탈퇴를 처리할 때, 소셜 계정과의 연결을 해제해주기 위해서 다시 한 번 로그인을 요청하게 되는것이다.

authorizationCode는 로그인을 요청해 가져올 수 있으니, 다음으로 JWT 생성 부분을 살펴보자.

Apple OAuth 프로세서에서는 클라이언트가 인증 서버에 요청할 때 Client Secret을 사용해 인증 요청을 진행하게 되는데, 이 Client Secret은 사실 JWT로 구성되어 있다고 한다.

JWT를 생성해 Client Secret를 만들기 위해서는 clientId, teamId, keyId, privateKey가 필요하다.

• clientId : Bundle Identifier
  XCode에서 확인 가능
  

• teamId
  Apple Developer에서 확인 가능
  

• keyId
  발급받은 암호화 키의 ID
  

• privateKey
  .p8 파일에서 확인 가능, 암호화 키 발급시 다운로드 받은 파일임
  

.p8이 열리지 않는 분들은 텍스트 편집기로 열어주시면 된다.

🔥 여기서 매우 중요한 부분이 있는데, 암호화 키와 관련된 어떤 데이터도 공개되서는 안되니 반드시 노출되지 않도록 주의해 주세요 !!!!

저는 임시로 블로그 작성을 위해서 발급 받은 키이기 때문에, 해당 블로그 내용과 관련된 모든 암호화 키나 식별자 들은 전부 삭제 예정입니다. 여러분들은 절대 노출 시키시면 안되요 !!

Adding Required Packages

Flutter에서 JWT생성을 간단하게 해주는 패키지와 API 호출을 위한 패키지를 추가해주자.

dependencies:
	dart_jsonwebtoken: ^2.17.0
	http: ^1.3.0

Generating JWT for Apple Authentication

앞서 살펴본 id나 키를 영역에 맞게 변경해 주시면 되고, iat, exp는 JWT 생성시간과 만료시간을 명시해주는 것이다. 만료시간이 지나면 당연히 애플 서버로 부터 인증이 거부된다.

각자가 구현하는 로직에 맞게 만료시간을 설정해 주시면 된다.

JWT({
	"iss": {your_team_id},
	"iat": DateTime.now().millisecondsSinceEpoch ~/ 1000,
	"exp": (DateTime.now().millisecondsSinceEpoch ~/ 1000) + 3600,
	"aud": "https://appleid.apple.com",
	"sub": {your_client_id},
	},
	header: {
		"alg": "ES256",
        "kid": {your_key_id},
	},
);

이제 생성한 JWT로 Clent Secret을 구성해 주도록 하자.

구성에 앞서 .p8파일의 암호화 키를 사용해야 하는데, 키를 사용할 때에 주의할 부분은 파일 내에 모든 텍스트가 포함되어야 한다는 것과 줄바꿈 상태도 유지되어야 한다는 것이다.

• Case 1

const String privateKey =
        "-----BEGIN PRIVATE KEY-----\nMIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgL11OH66VJoxfxZSQ\nTGpTW4vcXPVylbGYigSACKFr212gCgYIKoZIzj0DAQehRANCAARZlXVBlPY2L8Ao\n4kF61H0zzcSpTmEqVU22SJKOnIf3wnS6zNxBfIfl5q7IyUXcr21c5ni5zuMY8OGT\nv3NQQVpd\n-----END PRIVATE KEY-----";

• Case 2

const String privateKey = '''-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgL11OH66VJoxfxZSQ
TGpTW4vcXPVylbGYigSACKFr212gCgYIKoZIzj0DAQehRANCAARZlXVBlPY2L8Ao
4kF61H0zzcSpTmEqVU22SJKOnIf3wnS6zNxBfIfl5q7IyUXcr21c5ni5zuMY8OGT
v3NQQVpd
-----END PRIVATE KEY-----''';

Client Secret을 만들어 주기 위해 생성한 JWT에 Private Key로 서명(Signature)을 진행해 주면 된다.

여기서 ES256은 Apple이 요구하는 JWT 서명 알고리즘이며, Elliptic Curve Digital Signature Algorithm(ECDSA)를 기반으로 한다.

const String privateKey = '''...''';
final JWT jwt = JWT({...});

final String clientSecret = jwt.sign(
	ECPrivateKey(privateKey),
	algorithm: JWTAlgorithm.ES256,
);

Retrieving Access and Refresh Tokens

Client Secret을 생성 하였으니, 이제 API 관련된 통신만 수행하면서 연결을 해제할 수 있게 되었다.

Apple의 Revoke Tokens API를 호출하기 위해서는 Access(or Refresh) Token이 필요하기 때문에, 토큰을 먼저 발급받도록 하자.

토큰은 앞서 생성한 Client Secret과 애플 로그인을 통해 가져온 authorizationCode로 Access Token 또는 Refresh Token을 발급 받을 수 있다.

Future<void> getRefreshToken(String authorizationCode) async {
    try {
      final String clientSecret = _createAppleClientSecret();
      final http.Response response = await http.post(
        Uri.parse("https://appleid.apple.com/auth/token"),
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: {
          "client_id": {your_client_id},
          "client_secret": clientSecret,
          "code": authorizationCode,
          "grant_type": "authorization_code",
          "redirect_uri": "REDIRECT_URL",
        },
      );
      if (response.statusCode == 200) {
        // final data = json.decode(response.body);
        // data["refresh_token"];
        // data["access_token"]
      }
    } catch (_) {}
  }

정상적으로 Access Token과 Refresh Token을 발급 받았다.

Revoking Tokens

드디어 마지막으로 Apple에 서비스와의 계정 연결 해제만 요청하면 끝이다 !

Apple의 Revoke Tokens API 요청시에도 Client Secret은 필요하다.

Revoke Token의 API는 응답 값이 없으며, 200 코드로 성공 여부를 확인하거나 아니면 사용한 토큰을 다시 검증 받아 연결 해제를 확인하면 된다.

Future<void> revokeToken(String refreshToken) async {
    try {
      final String clientSecret = createClientSecret();
      final http.Response response = await http.post(
        Uri.parse("https://appleid.apple.com/auth/revoke"),
        headers: {"Content-Type": "application/x-www-form-urlencoded"},
        body: {
          "client_id": {your_client_id},
          "client_secret": clientSecret,
          "token": refreshToken,
          "token_type_hint": "refresh_token",
        },
      );
      if (response.statusCode == 200) {
        // success
      }
    } catch (_) {}
  }

연결이 정상적으로 해제 되었다면, Apple은 계정 정보 변경에 대한 안내 Email을 사용자에게 발송한다.

Test

Mac 또는 iPhone에서 Apple 계정에 접속해보면, Apple로 로그인한 내역을 확인할 수 있다.

Revoke Tokens 요청을 정상적으로 완료하게 되면 내역에서 더 이상 연결된 서비스가 보이지 않게 된다.

회원 탈퇴 또는 비활성화 등의 Apple과의 계정 연결을 해제하기 위한 절차를 정리해보면, 1️⃣authorizationCode를 가져오기 위해 애플 로그인을 요청하고 2️⃣암호화 키를 사용하여 JWT 서명 알고리즘으로 Client Secret을 생성, 3️⃣Access (or Refresh) Token을 발급 받아 4️⃣Revoke Tokens API를 요청하도록 해주면 된다.

Hiding Private Keys

토큰 무효화에 대해서 알아보았는데, 마지막으로 위에서 사용한 프라이빗 키를 숨기는 방법에 대해서 소개해 보려고 한다.

왜 숨겨야 할까 ? 개발을 하면서 팀과 협업하거나 오픈소스 프로젝트를 관리할 때, 프라이빗 키(API 키, 서비스 계정 키, 인증 정보 등)가 실수로 Git에 커밋되는 경우가 있다.
이러한 키가 외부에 노출되면 보안 사고가 발생할 수 있으며, 악의적인 사용으로 인해 시스템이 위험에 처할 수 있다. .gitignore, .env, 환경 변수(Environment Variables), Secret Manager 등의 정말 다양한 방법으로 키를 숨기고 보관할 수 있으니 각 환경과 팀의 성격에 맞는 방법을 찾아 사용하시면 된다.

이번에 소개할 방법은 Configiguration File로 관리하는 방법이다.

비공개 키나 내부적으로 사용하는 설정, 빌드 변형에 따른 환경 설정 등을 Config 파일로 관리하여 외부 저장소에 올리지 않고 팀 내에서만 공유하여 사용하도록 하는 방법이다.

사용 방법은 간단하다 .gitignore에 Config 파일을 등록하여 외부 저장소에 커밋되지 않도록 하고, Config 파일을 앱 초기 설정 또는 필요한 시점에 로드하여 사용하는 방법이다.

프로젝트 내 assets 폴더를 생성해주고, config.json 파일을 추가하여 숨기고 싶은 데이터들을 보관해 주면 된다.

config.json 파일에 숨기고 싶은 설정이나 데이터를 만들어주자.

{
  "clientId": {your_client_id},
  "teamId": {your_team_id},
  "keyId": {your_key_id},
  "privateKey": {your_private_key}
}

.gitignore 파일에 숨기고 싶은 폴더를 추가해 주면, Git에 포함되지 않는다. privates 폴더 전부를 제외 처리하였다.

assets/privates/

Flutter에서 json 파일을 로드하여 사용할 수 있다.

final String configJson = await rootBundle.loadString("assets/privates/config.json");
final Map<String, dynamic> data = json.decode(configJson);
print(data);

마무리

Sign in with Apple 기능에 대한 설정부터 로그인 및 탈퇴시 토큰을 무효화하는 방법까지 알아보았다.

생각보다 글의 내용이 너무 길어져 아쉽게도 안드로이드에서 애플 로그인을 사용하는 부분에 대해서 다루지 못하였는데, 안드로이드나 웹 관련된 방법은 추후 글을 작성할 예정이다.

글을 한 번에 작성하는게 아니라 시간날 때마다 조금씩 작성하다 보니 오타나 틀린 부분이 있을 수도 있습니다.

몇 달 만에 글을 게시하게 되었는데, 앞으로는 다시 주기적으로 글을 작성할 예정입니다. Flutter와 관련하여 궁금한 점이나 알고 싶은 기능이 있으시면 언제든지 요청해 주세요.

긴 글 읽어주셔서 감사합니다.

Sign in with Apple 기능과 관련된 부분이나 기타 궁금하신 내용은 댓글 남겨주시면 최대한 신속하게 답변 남기도록 하겠습니다 🐯