로그인
서비스를 제작할 때 고민되는 것 중 하나가 바로 회원가입과 로그인이다. 어떤 방식으로 회원가입과 로그인을 구현할지에 대해서 정해야하는데 요즘에는 보통 소셜 로그인을 많이 사용하는 것 같다.
개발자 입장에서는 로그인을 구현할 때 앱인지 웹인지에 따라, 자체 로그인인지 소셜 로그인인지에 따라 구현 방법이 각자 다르다. 그리고 각 방법마다도 클라에서 어디까지 처리할건지, 서버에서 어디까지 처리할건지에 따라 또 다 다르다고 할 수 있다.
오늘은 iOS 앱을 만드는 경우에 대해서 이야기 해볼 것인데 iOS 앱을 만드는 경우 애플 로그인을 꼭 붙여야지만 릴리즈가 쉽게 통과되기 때문에 애플 소셜 로그인을 꼭 할 줄 알아야한다.
소셜 로그인
우선 일반적인 소셜 로그인의 플로우에 대해서 이야기해보도록 하겠다. 지금부터 하는 얘기는 어느 플랫폼(웹, 앱)에서 소셜 로그인을 구현을 하든 공용되는 이야기이다.
사진 출처: kakao developers
설명의 편의를 위해 앞으로 다음과 같이 구분하도록 하겠다. 해당 단어들을 잘 구분하며 읽어야지 정확하게 소셜 로그인을 이해할 수 있다.
사용자 클라이언트: 우리가 우리의 서비스를 보여주기 위해 만드는 클라이언트
우리 서비스 서버: 우리가 우리 서비스의 구현을 위해 만든 서버
소셜 인증 서버: 소셜 로그인을 제공하는 곳에서 유저 인증을 위해 따로 구현한 인증 서버
소셜 API 서버: 소셜 로그인을 제공하는 곳에서 인증한 유저가 사용할 수 있는 API를 구현해놓은 서버
위의 사진을 보면 알 수 있듯이 소셜 로그인을 전체적인 부분을 세개로 분리할 수 있다.
첫 번째로는 소셜 인증 서버(사진에서는 카카오 인증 서버)로 소셜 서비스의 로그인을 하는 과정이다.
두 번째로는 로그인한 소셜 서비스를 통해 소셜 API 서버의 API를 이용해 로그인한 사용자의 정보를 가져오고 우리 서비스 서버에 그런 내용을 가진 유저가 있는지 확인하고 없다면 우리 서비스 서버에 가입을 시켜주는 과정이다.
세 번째로는 우리 서비스 서버에 로그인을 시켜주는 것이다.
앱을 만들고 있던 웹을 만들고 있던 위의 3단계는 일반적으로 비슷하게 가져간다고 생각하면 된다.
첫 번째 단계를 조금 더 자세히 뜯어보자 크게 봤을 때는 소셜 API 서버에 사용할 수 있는 토큰을 발급받는 과정이지만 세부적으로는 단계가 몇개 더 있다.
우선 사용자 클라이언트가 로그인할 소셜 서비스를 고른다면 우리 서비스 서버 입장에서는 소셜 인증 서버로 인증 코드(authorization code)를 달라고 요청한다. 이때 사용자에게 어느 범위까지 자신의 정보를 제공할 것인지 고르한다. 완료되면 authorization code를 발급받으며 발급받은 코드를 소셜 인증 서버의 accessToken을 받는 데에 사용할 것이다. 그렇게 결과적으로 우리는 소셜 API 서버에서 사용할 소셜 서비스의 access token을 받을 수 있다.
두번째 단계에서는 첫번째 단계에서 받은 소셜 서비스의 accessToken을 이용해 소셜 API 서버의 사용자 정보 불러오기 API를 사용할 것이다. 해당 API 결과를 확인해보면 소셜 서비스에서 유저를 식별하기 위한 유저 고유값이 존재하는데 이것을 이용해서 우리 서비스 서버에 가입한 유저인지 확인할 수 있다. 우리 서비스 서버의 데이테베이스에 유저가 있음이 확인되면 세번째 단계로 넘어가면 되고 유저가 존재하지 않는다면 새로 가입을 시켜주면 된다.
세번째 단계는 우리 서비스 서버의 로그인 처리를 해주는 것이다. 본인이 세션 방식을 채택했다면 세션을 사용하고 JWT 방식을 채택했다면 JWT 방식에 맞게 사용자를 로그인시켜주면 된다.
애플 로그인
위에서는 일반적인 소셜 로그인의 플로우에 대해서 설명을 했다. 그런데 우리의 애플은 조금 다른 플로우를 가지고 있다. 애플은 위의 첫번째 단계에서 반환해주는 것이 accessToken이 아니라 identityToken이다.
사진 출처: Apple Developer
애플 공식 문서에서 identityToken에 어떤 값이 있는지 확인할 수 있다.
identityToken은 accessToken처럼 다른 API의 Authorization을 위해서 사용하는 것이 아닌 token 자체에 사용자의 정보를 담고있다. 그렇기 때문에 위의 소셜 로그인 과정처럼 accessToken으로 사용자의 정보를 불러올 필요가 없다.
identityToken을 전달받았다면 다음 애플 공식 문서에 맞게 identityToken의 유효성 검사를 한다. 유효한 identityToken이라면 identityToken을 JWT decode해서 유저 고유값을 이용해서 유저를 가입시키거나 로그인시켜주면 된다.
즉 일반적인 소셜 로그인보다 소셜 서버와 통신을 하는 횟수가 1번 적다고 생각하면 된다.
