[Oauth2.0] Apple 로그인 구현 논의사항2
팀 전체 회의 전 백엔드 회의에서 논의한 내용과 공식 문서를 다시 한번 확인한 내용을 바탕으로 정리해보려 한다.
Apple 로그인 구현 논의사항1 복기
1-1. 어떤 토큰을 받아야 할까?, 1-2. client secret
1-1 중 "refresh 토큰을 프런트로부터 로그인을 위해 받는 것이 좋을 것 같다는 생각이다."의 경우 공식 문서를 다시 살펴본 결과 잘못된 판단이었다.
공식 문서에서 제공하는 유저 검증 시퀀스 다이어그램을 다시 한번 살펴보자.
프런트는 앱 서버에 ID 토큰과 인증코드를 전달하고 refresh 토큰조차 제공받지 않는다.
프런트의 역할은 앱 서버에 ID 토큰과 인증코드를 전달하는 것까지이다.
이후 Apple ID 서버에서 제공받은 토큰에 대한 관리는 앱 서버에 있는 것을 확인할 수 있다.
2. MemberInfo 조회 및 회원가입 문제
우선 "인증 제공자에서 제공하는 이름을 사용하지 못한다." 문제의 경우 두 가지 해결 방안이 나왔다.
첫 번째 방법의 경우 "귀여운기린"과 같은 임의의 닉네임을 지정해주는 것이다.
두 번째 방법은 가입 이후 바로 닉네임 변경 페이지로 넘어가는 것이다.
첫 번째 방법의 경우 다른 로그인을 하였을 때와 결과가 다르게 나오기에 통일성이 떨어지는 문제가 있고
두 번째 방법의 경우 디자이너 및 프런트의 추가적인 작업이 필요하다는 문제가 있었다.
"MemberInfo 조회" 문제의 경우 Apple 로그인에 맞는 새로운 메서드를 만드는 방향으로 논의를 진행하였다.
기존의 카카오 로그인과 다르게 MemberInfo를 조회하는 것이 아니라 토큰을 검증하고 그것을 디코드하여 Member에 대한 정보를 얻는 방법이기에 새로운 메서드를 만드는 것이 적절해 보인다.
로그인 앤드포인트 분리
논의하면서 들었던 팁은 "동일한 버튼을 눌렸을 때, 분기를 나누지 않는 설계가 좋은 설계다"이다.
그렇기에 현재 코드에서 로그인과 회원가입을 동일한 컨트롤러에서 처리하는 것이다.
하지만 그런데도 로그인 앤드포인트를 분리하는 이유는 우선 생각해보면 카카오 로그인과 애플 로그인은 하나의 버튼이 아니다.
분리된 버튼이다.
위의 사진은 velog의 로그인 버튼을 눌렀을 때 이동하는 주소 목록이다.
위에서 확인할 수 있듯 버튼이 분리된 만큼 각 소셜 로그인의 이동하는 주소가 다른 것을 확인할 수 있다.
그리고 로그인 앤드포인트를 분리해야 하는 추가적인 이유는 Apple 로그인을 위해 받아야 하는 정보가 카카오 로그인을 위해 받아야 하는 정보와 차이가 크다.
카카오 로그인을 위해 받아야 하는 정보가 토큰뿐이지만 위의 사진에서 확인할 수 있듯 Apple 로그인을 위해 받아야 하는 정보는 위에서 확인할 수 있듯 토큰뿐 아니라 많다.
그렇기에 현재는 로그인 앤드포인트 분리 제안이 나왔기에 "새로운 앤드포인트에서는 Apple 로그인에 맞는 새로운 DTO를 만드는 것도 좋지 않을까?"라는 논의하였다.
현재 논의하고 있는 것은 앱에서 처음 로그인하면 받을 수 있는 위 사진의 정보를 그대로 받을 수 있는 DTO를 받는 것이다.
