[스터디] 네이버, 카카오 소셜 로그인과 RefreshToken

카카오 로그인 과정

출처 : 카카오 개발자 센터

1. 카카오 로그인

1. 1. 사용자가 서비스에서 카카오 로그인 버튼을 클릭합니다. 서비스는 카카오 인증 서버로 인가 코드 발급을 요청합니다.
2. 2. 카카오 인증 서버는 사용자에게 인증을 요청합니다. 
   • - 카카오톡으로 로그인: 카카오톡 실행, 카카오톡에 연결된 카카오계정의 자격정보(Credentials)로 사용자 인증
   • - 카카오계정으로 로그인: 계정 정보를 입력해 로그인하는 화면 출력, 해당 카카오계정의 자격정보로 사용자 인증
3. 3. 카카오 인증 서버는 사용자 인증 성공 시, 서비스 앱의 동의항목 설정을 바탕으로 사용자에게 동의 화면을 출력합니다.
4. 4. 사용자가 필수 동의항목에 동의하고 로그인을 요청하면, 카카오 인증 서버는 인가 코드(Authorization Code)를 발급해 서비스 앱에 등록된 Redirect URI로 전달합니다.
5. 5. 서비스는 전달받은 인가 코드로 토큰을 요청하여 받습니다.

2. 회원 확인 및 가입

1. 1. 서비스는 카카오 로그인을 완료하여 발급받은 토큰으로 사용자 정보 가져오기를 요청합니다.
2. 2. 카카오 API 서버는 요청 시 사용된 토큰의 유효성을 검증하고, 요청을 처리하고 서비스에 응답합니다.
3. 3. 서비스 서버는 카카오로부터 제공받은 사용자 정보로 해당 사용자가 서비스에 회원 가입되어 있는지 확인합니다.
   • - 이미 회원 가입된 사용자: Step 3의 서비스 로그인 단계 수행
   • - 아직 회원 가입되지 않은 사용자: 카카오에서 제공받은 사용자 정보로 서비스 데이터베이스에 회원 가입 처리

자세한 내용은 https://developers.kakao.com/docs/latest/ko/kakaologin/common

Kakao Developers

 

네이버 로그인 과정

 

자세한 내용은 https://developers.naver.com/docs/login/devguide/devguide.md#2-1-%EB%84%A4%EC%9D%B4%EB%B2%84-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

네이버 로그인 개발가이드 - LOGIN

 

구현해보고 느낀점

1. 카카오는 param에 인가코드만 받아서 간단한데, 네이버는 인가코드, state까지 받아야해서 귀찮다.

2. 카카오는 redirectUrl 중복이 가능한데, 네이버는 불가능해서 두 개를 생성하고 바꿔가면서 테스트해야해서 번거롭다.

- 카카오는 url만 바꿔주면 실행가능

- 네이버는 url, client_id, client_secret 까지 전부 바꿔줘야함

네이버

카카오

3. 참고할만한 레퍼런스들이 생각보다 많지 않다.(친절하게 쓰여져있는 글들이 없다.)

 

둘 다 단점이 너무 크기 때문에 다른 소셜 로그인을 추천한다..(구글)

 

OAuth와 OAuth2

 

요 두 개의 차이점은 코드를 작성하기 전에 다른 블로그를 참고해서 개념을 익혔는데 다른 블로그를 찾아보니까 그게 아닌 것 같았다.

그래서 챗GTP한테 물어봐서 다시 개념 정리를 했다.

 

OAuth(개방형 인증)와 OAuth 2.0은 서로 관련되어 있지만 인증 및 웹 리소스에 대한 액세스 권한 위임에 사용되는 별개의 프로토콜

1. OAuth 1.0 대 OAuth 2.0: OAuth 1.0은 OAuth 프로토콜의 원래 버전인 반면, OAuth 2.0은 OAuth 1.0의 한계를 개선한 더 새롭고 포괄적인 프로토콜입니다.
2. 복잡성과 단순성: OAuth 1.0은 일반적으로 OAuth 2.0보다 더 복잡한 것으로 간주됩니다. OAuth 2.0은 이전 버전에 비해 더 간단하고 유연하며 구현하기 쉽도록 설계되었습니다.
3. 토큰 처리: OAuth 1.0은 주로 디지털 서명을 사용하여 토큰을 보호하는 반면, OAuth 2.0은 주로 인증 서버에서 발행한 토큰(예: 액세스 토큰 및 새로 고침 토큰)을 사용합니다.
4. 보안: OAuth 2.0에는 OAuth 1.0에 비해 몇 가지 보안 개선 사항이 포함되어 있습니다. 예를 들어 OAuth 2.0에는 HTTPS, 토큰 만료 및 향상된 클라이언트 인증 메커니즘에 대한 지원이 도입되었습니다.
5. 호환성: OAuth 2.0은 최신 웹 서비스 및 API에서 더욱 광범위하게 채택되고 지원됩니다. 많은 주요 기술 회사와 플랫폼이 OAuth 2.0으로 마이그레이션했거나 OAuth 1.0과 OAuth 2.0을 모두 지원합니다.
6. 확장성: OAuth 2.0은 대규모 애플리케이션 및 최신 웹 개발 방식에 더 적합합니다. 다양한 유형의 클라이언트 및 사용 사례를 처리하기 위한 더 많은 옵션을 제공합니다.

OAuth 2.0은 단순성, 유연성 및 광범위한 채택으로 인해 대부분의 새로운 애플리케이션 및 통합에 권장되는 선택이다. 그러나 일부 기존 시스템에서는 여전히 OAuth 1.0을 사용하거나 두 OAuth 버전에 대한 지원이 필요할 수 있다.

 

리프레시 토큰

리프레시 토큰 개념도 잘못알고 있던 부분이 많았다.

리프레시 토큰이 나중에 액세스 토큰의 역할을 하는 줄 알았는데, 알보고니까 이 토큰을 이용헤서 액세스 토큰을 재발급 받는데 이용하는 거였다..!!!

출처 : 인프런

refresh_token을 쓴다면, 보통 클라이언트에서 access token이 만료될때를 계산해서 refresh_token을 요청한다. 백엔드는 refresh token 발급 요청이 들어오면, 새로운 access token을 발급해주면 된다.