티스토리 뷰

사이드 프로젝트인 Foodbowl 앱의 서버 개발을 진행하면서 회원을 관리하기 위한 회원가입/로그인 기능이 필요하였습니다. 회원가입/로그인 기능을 위해 Apple OAuth 방식을 선택하게 되었는데, 선택 과정과 구현 과정을 기록하기 위해 글을 작성하게 되었습니다.

 

하나의 글로 작성하기에는 많은 내용이 담길 것이라 생각되어 여러 개의 글로 나누어 정리해보고자 합니다.

OAuth 선택 이유

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준이다. 다시 말해서, 사용자는 각각의 서비스에 로그인하는 것을 피하고 한 번의 로그인으로 여러 서비스를 이용할 수 있게 된다. 카카오, 네이터, 구글, 애플 등 다양한 기업에서 OAuth를 이용해서 서비스를 제공하고 있다.

 

회원가입을 직접 구현한다면 아이디, 비밀번호 등 다양한 정보를 직접 입력하여 회원가입을 진행하게 되는데 사용자 입장에서 번거롭고 개인정보를 제공해야 한다는 불안을 느끼게 된다.

 

하지만 OAuth를 사용하면 회원가입 되어있는 외부 서비스에 로그인만 하면 되기에 간편하게 회원가입을 진행할 수 있고, 서비스 회원가입 시 정보 제공을 동의했던 부분에 대해서만 정보를 노출한다는 점도 사용자에게 매력적으로 다가온다. 또한 자체적으로 인증을 관리하면 아이디 찾기, 비밀번호 찾기 등과 같은 고객 서비스도 부가적으로 필요하게 되는데, OAuth를 통해 외부 서비스로 해당 역할을 위임할 수 있다.

 

결론적으로 OAuth를 선택한 이유는 다음과 같다.

  1. 사용자 경험 측면에서 편의성
  2. 관리 측면에서 개발 편의성

Apple OAuth 선택 이유

카카오, 네이버, 구글 등 선택할 수 있는 선택지가 많았지만 Apple OAuth를 최우선으로 선택한 이유는 개발 중인 앱이 iOS앱이기 때문이다. App Store에 등록되기 위해서는 다양한 조건의 충족이 필요한데 그중 소셜 로그인 서비스를 사용하는 앱에 대해서는 Apple 로그인을 동등한 옵션으로 제공해야 한다.

 

자체적으로 회원가입을 구현한다면 넣지 않아도 되지만 OAuth를 사용하기로 했기에 Apple OAuth 구현이 필요했고, 최우선으로 구현해 보기로 결정하였다. 추후에 다른 OAuth도 추가할 계획이 있다.

App Store 심사 지침

Apple OAuth

Apple OAuth 문서1

Apple OAuth 문서2

보다 자세한 내용은 위의 공식문서를 통해 확인할 수 있다.

전체적인 흐름은 위의 사진과 같다.

  1. 사용자는 Apple 계정으로 로그인한다.
  2. Apple 계정 정보를 확인하고 검증하여 Apple ID servers에게 회원 토큰을 요청한다.
  3. 사용자 상태가 포함되어 있는 회원 토큰을 응답한다.
  4. 필요에 따라 인증 코드와 회원 토큰을 바탕으로 애플 서버가 관리하는 access token과 refresh token 발급을 요청한다.

각 단계에 대해 조금 더 자세히 알아보도록 하자.

클라이언트는 Apple 로그인을 버튼을 통해 애플 계정 로그인하게 된다. 이때, ID, PW 암호를 직접 입력할 수도 있고 Face ID 또는 Touch ID를 사용할 수도 있다. 클라이언트에서 로그인된 계정 정보를 애플 API를 통해 전달하게 되고 유효한 계정이라면 Apple ID servers로 토큰을 요청하여 클라이언트는 Apple ID servers로부터 회원 토큰을 받게 된다.

 

회원 토큰은 JWT(JSON Web Token)이며 아래의 클레임을 포함하고 있다.

  • iss : ID 토큰을 발급하는 보안 주체를 식별한다. Apple이 토큰을 생성하기 때문에 https://appleid.apple.com 값을 가지고 있다.
  • sub : ID 토큰의 주체를 식별한다. 사용자의 고유 식별자를 의미한다.
  • aud : ID 토큰의 수신자를 식별한다. 개발자 계정의 client_id를 의미한다.
  • iat : 클레임이 발급된 시간을 의미한다.
  • exp : 토큰이 만료되는 시간을 의미한다.
  • nonce : 클라이언트와 ID 토큰을 연결하기 위한 문자열이다. 특정 클라이언트로부터 발급된 토큰인지 확인할 때 사용한다.
  • email : 사용자의 이메일 주소를 나타내는 문자열이다.

그 외에도 많은 클레임이 존재하지만 대표적인 클레임만 정리하였다. JWT를 복호화하여 위의 정보를 추출하여 애플리케이션 서버에서는 회원가입을 진행할 수 있다. 필요에 따라 서버 자체적으로 토큰을 생성하지 않고 애플 서버로부터 access token과 refresh token을 받아서 인증에 사용할 수 있다.

 

프로젝트에서는 애플 서버로부터 access token과 refresh token을 받는 것이 아닌 자체적으로 토큰을 관리하도록 하였다. 그 이유는 우리 서버에서 자체적으로 토큰을 관리할 수 있다고 판단하였고 다른 OAuth를 도입하는 것을 고려해 보았을 때도 토큰 형식을 통일하는 것이 관리하는 비용을 줄일 수 있다고 생각했기 때문이다. 또한 외부 서비스 호출을 줄일 수 있다는 장점도 존재하였다.

최종적으로 애플리케이션 서버와 연동한 플로우는 위와 같다.

  1. 클라이언트는 애플 계정으로 애플 서버에 로그인을 요청한다.
  2. 유효한 계정이라면 애플 서버는 클라이언트에게 애플 토큰을 발급한다.
  3. 클라이언트는 애플 토큰으로 애플리케이션 서버에 회원가입/로그인을 요청한다.
  4. 유효한 애플 토큰이라면 회원 정보를 바탕으로 서버 인증 토큰을 발급한다.
  5. 클라이언트는 서버 인증 토큰을 통해 로그인 상태를 확인할 수 있다.

마치며

Apple OAuth는 다른 OAuth 방식과 조금 다른 부분이 있어 플로우를 이해하는데 시간이 조금 걸리게 되었던 것 같습니다. 그래도 한번 제대로 이해하고 나니 OAuth가 전체적으로 어떤 흐름으로 진행되는지 그릴 수 있게 되었던 것 같습니다. 다음 글은 Apple OAuth 과정을 직접 코드로 구현했던 과정을 정리해보고자 합니다 :)

댓글
최근에 올라온 글
최근에 달린 댓글
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Total
Today
Yesterday