221120 서드파티 로그인 업그레이드를 위해 생각해본 것들

샨티(shanti)·2022년 11월 20일
0

하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.

이번 한 주는 가히 네이버/카카오 로그인과 투닥인 한 주라고 말 할수 있겠다.
하지만 중요한건 싸움이 끝날 기미가 안..보.....여...

어제 카카오 액세스 토큰까지 받아오는 건 구현했는데 그걸 어떻게 활용해야 할지도, 또 네이버는 어떻게 구현해야 할지도 잘 모르겠고. 계속 백엔드쪽 코드만 구현하고 있자니 약간 지치는 마음이 있어서 오늘은 프론트 UI 구현과 서드파티 로그인 구현을 좀 번갈아가면서 진행하려 노력했다.
드라이브가 좀 떨어질 때 어떻게든 끌어올려야 하는 것 역시 본인의 몫이기 때문에!! 최대한 쳐지지 않도록 꾸역 꾸역 할 수 있는 방법을 찾는 중이다.

우선 카카오 로그인 관련해서는 복잡하고 난잡한 생각들만 가득했기에 화이트보드를 활용하기로 결정했다.
처음엔 이렇게 낙서마냥 끄적이다가...

지난번에 홀맨님께서 말씀해주고 가신 InfraStructure 레이어를 포함하여 4 layered architecture 구조에서 서드파티 로그인을 어떻게 구현할 수 있을지 도식화를 해 보았다.


어제 카카오 API와 통신하는 클래스를 'KakaoLoginService'라고 생성해놓고는 Infrastructure 패키지에 넣어두었는데 이 그림을 그리면서 다시 생각해보니 좀 이상했다.
Infrastructure는 application layer가 아니다. 즉 Application layer의 경우 UI layer와 domain layer 사이에서 이들과 맞닿아있어야 하는 것이고, Infrastructure layer는 상기 UI Layer, Application Layer, Domain Layer 어느곳에서나 접근이 가능해야 할 것이다.

이미 만들어놓은 것에서 가장 비슷한게 무엇일까? 생각해봤는데 Utils 패키지 안에 있는 JWTUtil 클래스였다.

그래서 KakaoLoginService 클래스의 이름을 KakaoLoginUtil로 바꾸고 그 안에 아무 생각 없이 붙여두었던 Service 어노테이션을 제거했다.
JWTUtil처럼 모든 레이어에서 사용이 가능하도록 WhereWeGo(내 서비스 이름)Application 클래스 안에서 Bean으로 등록해주었다.
이 방향이 맞는건가? 잘 모르겠지만 우선 내일 노아님의 피드백을 받기로 결정하고 이어나갔다.

그 다음 헷갈렸던 것.
카카오와 네이버가 access token, refresh token을 주긴 하는데 얘네들의 역할을 정확히 모르겠다. (어제 TIL에도 쓴 부분)
그래서 우선은 되는 모양새를 구현해보려고 이들에게서 받은 access token을 프론트에 넘겨주면서 쭉 작업을 이어갔는데... 지금 TIL을 쓰기 직전 동료와 이야기를 하다가 번뜩 생각이 들었다.

access token이 매번 바뀌는 상황에서(적어도 카카오 로그인은 로그인 때마다 다른 액세스 토큰을 주더라.) 이걸 프론트쪽에서 서버로 넘겨줘봐야 서버측 JWTUtil에서 decode를 시킬수가 없다... 읍읍.

진짜 번쩍. 머리를 스쳐가는 생각에 곧바로 네이버에서 받은 액세스토큰을 복사해서 JWT 홈페이지에 가 decode를 해보았는데 안먹힌다. 흡.

어제부터 계속 카카오, 네이버가 준 액세스토큰을 바로 갖다 써도 되는지에 대한 의문이 있었는데 그래선 안되겠다는 생각이.. 든다. 아니면 내가 방향성을 잘못 잡은 것일수도 있고.

지금 생각으로선, 카카오/네이버에서 사용자 세부정보를 가져올 때 unique 값으로 가져오는 user id가 있다.
이를 받아와서 DB에 저장해둔 뒤에 카카오/네이버 로그인이 인증되는 순간 그 user id를 encode 해서 액세스 토큰으로 넘겨줘야 할 것 같다. 그래야 불변하고, 디코드를 했을 때 유저 정보와 비교도 할 수 있고.

다만 의문인건 이 unique값을 내가 보유해도 문제가 없는지..? 물론 포트폴리오이기는 하지만 카카오/네이버 로그인을 구현하면서 '개인정보를 어느 범위까지 저장할 수 있는가?'에 대한 고민이 좀 많아지는 것 같다.

마지막으로 헷갈렸던 점.
카카오/네이버 유저이기는 하나 내 서비스의 유저가 아닐 경우의 처리.
생각해보니 별도의 회원가입 처리가 필요하지 않을 것 같다. 엄밀히 말하면 추가 정보 입력을 요구하는 것이지 그 이외에 strict한 가입절차는 생략이 가능해보인다.
그래서 로그인을 시도하여 카카오/네이버의 인증을 받은 유저의 정보는 db에 저장되나 unregistered의 상태값을 부여하고, 추가정보 입력을 통해 약식 sign-up 과정을 거치면 이 유저의 상태값을 registered로 변경하는 것으로 구현해보고자 한다.

지금은 access token에 대한 부분이 해결되지 않아 카카오/네이버와 통신 했다! 정도로만 구현했는데 갈길이 먼 것 같다. 아이고...


우선 상단 바에 '로그인' 버튼을 추가하여 서드파티 로그인이 완료된 경우 '로그아웃'으로 변하게 했다.


로그인을 마친 후 My메뉴에서 확인하는 내 정보.
닉네임인 '또또누나'는 네이버에 입력되어 있는 내 닉네임을 자동으로 가져온 것이다.
이건 언제든지 변경이 가능하도록 할 예정.
아 근데 또 지금 막 이 글을 쓰면서 생각이 드는게....
닉네임은 원칙적으로 중복이 되지 않도록 하고 싶었는데........... 단순히 네이버, 카카오에서 가져온 닉네임을 user nickname 값으로 준다면... 중복될 가능성이 아주아주아주아-주 농후하겠구나... 하하하하하하..............
생각할수록 뭐가 많아지네..? ^^

아.. A ㅏ.... ㅎ ㅏ..

아이정보와 즐겨찾기는 도저히 할 시간이 없어서 다음 스프린트로 미룬다. 윽 ㅠ


오늘 너무 진도가 안나갈 때 기분이라도 내려고 만든 닉네임 변경하기 페이지 UI.
근데 중복되는 닉네임이 발생하는게 전제되어 있는데.. 이 페이지 ..... 의미있냐..?

휴. 우선 내일 오전까지 지금 널어둔 것들 마무리 하고 스프린트 회의 준비해야겠다.

힘!!!!!!!!!!내자고!!!!!!!!!!!!!!! 뽜!!!!!!!!!!!!!!!!!!!!!

profile
가벼운 사진, 그렇지 못한 글

0개의 댓글