💻 소셜 로그인

카카오 소셜 로그인

이번 앱잼에서 가장 먼저 맞게 된 파트이자, 내가 완전 문외한인 카카오 로그인을 구현하려 한다.
먼저 OAuth2.0 개념의 이해를 위해 생활코딩 유튜브 영상을 참고해 공부하였다.

---

OAuth2.0

Resource Owner, Resource Server, Client로 구분지었다.
이하 resource는 생략하고 작성하였다.

OAuth2.0의 기본 아이디어

1. client는 server에 등록, id와 secret을 제공 받음
2. client가 owner에게 로그인 승인 버튼 제공
3. server가 owner에게 정보 제공 동의 버튼 제공
4. server가 client에게 'code'라는 owner가 동의했음을 나타내는 정보를 제공
5. client가 server에게 id와 secret을 code와 함께 반환, 이로서 access token을 제공 받음
6. 이후 client는 access token을 이용해 요청, server는 자신이 부여했던 토큰이면 수락 및 resource 제공
7. client는 받은 resource를 알맞게 가공해 owner에게 제공

이 중 5번부터가 내가 구현해야하는 부분이였다.

우리는 카카오 로그인만 구현했기 때문에, 원칙대로 provider도 돌려 받긴 했지만 아직 쓰지는 않았고

authentication code, client id, client secret을 통해 정보를 받아오는 api를 작성했다.

---

먼저 시도했던 파이어베이스 인증!

firebase auth

기본적으로 firebase authentication이 제공하는 로그인 방법이 꽤 있다.
google, facebook, twitter, github 등등.. 그렇지만 카카오톡은 없다.
대신 커스텀 토큰을 생성하는 방법이 있다.

![https://velog.velcdn.com/images%2Fozzing%2Fpost%2F378c67e6-2f60-41cc-94d5-27465d8aed98%2Fimage.png%5D(https%3A%2F%2Fimages.velog.io%2Fimages%2Fozzing%2Fpost%2F378c67e6-2f60-41cc-94d5-27465d8aed98%2Fimage.png)

access token으로 Kakao API에 정보 요청을 해서 잘 작동하는지 확인 후 firebase admin SDK를 사용해 firebase authentication에 user를 생성한다.

생성된 파이어베이스 사용자의 UID를 통해 firebase custom token을 서버에서 생성한다. 기기에 전달 후 signInWithCustomToken 메소드에 이를 넘겨 로그인 한다. 생각보다 엄청 간편했다.

실제로 파이어베이스 유저를 등록하고 UID를 불러오는 등의 코드를 작성해 보았지만 문제가 생겼다.

해당 프로젝트에서는 Firebase에서 유저를 식별하는데 사용하는 이메일을 카카오로부터 받아오지 않았다. 그저 식별자와 닉네임 정도의 정보만 요구했다. 따라서 어떻게 유저를 등록하고 어떻게 토큰을 생성할지 고민이 되었다.

---

인증 방식 변경

firebase auth를 사용하지 않기로 했다.
물론 firebase authentication의 장점도 있었고 아래와 같다.

• 이메일 / SNS / 익명 로그인이 전부 가능
• 내 이해 범위를 뛰어 넘는 좋은 보안
• firebase auth를 사용하면 강제로 로그아웃을 시킬 수 있음

회원가입 시점에 입력받은 사용자의 아이디로 임의로 이메일 형태의 문자열을 생성해서 사용하거나, 카카오 측에 이메일을 요구할 수도 있었으나 번거롭기 때문에 내가 아는 범위 안에서 간단한 방식으로 해결하고 싶었다.

따라서 카카오에게 돌려받은 회원 식별 번호만으로 유저를 식별하고, 우리 서버 내에서는 해당 유저 정보를 지닌 JWT 토큰으로 사용자를 식별하는 방식을 선택했다.

---

카카오 로그인으로 돌아가서

인가 코드와 provider를 넘겨주는 것 까지는 클라이언트의 범위이지만, 나는 일단 공부겸 클라를 기다리는겸 혼자 연습해보았다.

검색하면 많이 나오는 방식으로 KAKAO DEVELOPERS에서 어플리케이션을 등록하고,

<https://kauth.kakao.com/oauth/authorize?response_type=code&redirect_uri=>{내 콜백 URI}&client_id={내 카카오 클라이언트 아이디}

해당 uri로 이동하면 다음과 같은 페이지가 등장한다.

![https://velog.velcdn.com/images%2Fozzing%2Fpost%2F8c55b7a0-8f99-49ae-8526-51301830f4f7%2Fimage.png%5D(https%3A%2F%2Fimages.velog.io%2Fimages%2Fozzing%2Fpost%2F8c55b7a0-8f99-49ae-8526-51301830f4f7%2Fimage.png)

위 페이지에서 로그인을 하면 아래와 같은 URI의 페이지로 이동한다.

{내 콜백 URI}?code={인가코드}로 인가 코드를 얻을 수 있다.

이렇게 얻은 해당 인가 코드를 가지고 로그인 API에서 https://kauth.kakao.com/oauth/token로 POST를 날리면, 어세스토큰, 리프레시토큰을 돌려준다.

이후 돌려 받은 두개의 토큰으로 https://kapi.kakao.com/v2/user/me에 GET을 날린다.

그러면 유저의 카카오 프로필을 돌려주는데 이 때 카카오에서 제공하는 유저 ID가 위에서 말한 유저의 식별번호 역할이다.

---

로그인/회원가입

드디어 얻은 유저 식별번호로 DB를 조회했다.

서버 오류라던가 필요한 값이 없다거나 뭐 그런 걸 제외하고 크게 세가지 response가 존재한다.

1. 카카오 로그인 성공, 해당 데이터베이스에 유저가 존재하는 경우 → 로그인 성공
2. 카카오 로그인 성공, 그러나 해당 데이터베이스에 유저가 존재하지 않는 경우 → 회원 가입 필요
3. 카카오 로그인 실패 → 인가 코드나 토큰 문제

먼저 첫 번째 경우에는 해당 유저의 JWT 토큰 (access, refresh)을 만들어 반환하였다.

두 번째 경우에는 회원가입을 위해 필요한 정보를 돌려주었다.

이 정보와 사용자가 입력한 닉네임 등을 가지고 회원가입 API에 요청한다.
회원가입에 성공하고 나면 마찬가지로 JWT 토큰(access, refresh)을 만들어 반환한다.

우리의 경우에는 사용자 프로필 아이디(인스타 아이디 느낌)만 중복체크 해주었다.

세 번째 경우에는 로그인 실패 메시지를 돌려준다.

---

로그인/회원가입 리팩토링

위의 방식이 잘못되었다는 사실을 깨닫게 되어, 로직을 알맞게 바꾸고자 팀에 리팩토링을 제안하게 되었다. 같이 소셜 로그인을 담당했던 프론트 팀원이 팀을 나간 바람에, 바꾸고 싶지만 고민하던 중에 다른 프론트 팀원이 선뜻 좋다고 해주어서 진행할 수 있었다.

2번 케이스에서 회원 가입이 필요할 때 클라에게 고스란히 넘겨줬던 accesstoken, refreshtoken 이 두 가지 토큰 정보는 노출되서는 안되는 정보였고, 이 때문에 로직 자체를 변경하였다.

기존 로직

가입 회원 로그인 성공 -> 회원 정보 반환

미가입 회원 로그인 성공 -> 카카오 aT, rT 반환

로그인 실패 -> 에러 처리

바뀐 로직

가입 회원과 미가입 회원을 분리하지 않고, 로그인 성공 시 무조건 가입된 것으로 취급하였다. 해당 프로젝트에서는 가입 이후에도 홈으로 이동하기 전 유저가 직접 입력해야하는 정보가 있기 때문에 이를 통해 두 회원 그룹을 구분하였다.

가입 회원 로그인 성공 -> DB 조회 이후 회원 정보 반환 -> 홈

미가입 회원 로그인 성공 -> DB에 회원 생성 이후 회원 정보 반환
-> 필수 입력 내용 작성 -> 홈

이를 통해 두 토큰이 노출되는 일을 막을 수 있었다. 또 회원 가입 자체의 로직은 하나로 통일 되면서 중복 코드도 사라졌다.

---

JWT 토큰

모든 로그인이 필요한 페이지에서 매번 JWT 어세스 토큰을 헤더로 넘긴다. 유저를 식별하는데 사용하지만 언제까지나 쓸 순 없다.

만료되면 클라이언트 측에서 갖고 있던 JWT 리프레시 토큰을 함께 서버에 넘겨주고, 서버에선 유효한 리프레시 토큰인지 확인한 뒤 다시 JWT 토큰을 발급해서 반환한다.

여기서 필요한건 JWT 토큰이 만료되었을 때 알려주는 리스폰스와, 이 때 프론트에서 리프레시 토큰과 함께 JWT 토큰 재발급을 요청하도록 하는 API이다.

그러나 앱잼 동안에는 어세스 토큰 기간을 늘려 단순히 이것만을 가지고 로그인을 구현하였다.

보통 어세스 토큰은 1시간, 리프레시 토큰은 2주 정도로 설정하는 듯 하다. 앱잼 기간동안 개발을 위해 7일로 설정해 두었지만, 릴리즈 시점에는 저렇게 바꾸어야 겠다.

---

JWT 토큰 리팩토링

위와 같이 Access Token 기간을 무작정 늘려 사용하는 것은 보안적인 측면에서 좋지 않다. 또, Refresh Token을 사용하지 않아 자동 로그인 기간을 연장할 수 없었다.

따라서, Access Token이 만료되면 프론트에서 Refresh Token과 함께 요청하는 리프레시 API를 작성하였다. 받은 Refresh Token의 유효성을 검사하고 유효한 경우 다시금 해당 유저의 ID로 두 가지 토큰을 발급하여 돌려주었다.