express CRUD 겨우할 수 있는 코린이의 소셜 로그인 구현기
참고 사이트

OAuth가 뭐야?

우리 서비스에 카카오나 네이버, 구글과 같은 소셜 계정으로 사용자를 로그인 시키고 싶을 때 가장 간단한 방법은 사용자로부터 구글과 같은 서비스의 id, password를 우리 서비스에 직접 저장하여 활용하는 방법이다. 하지만 이와같은 방법은 보안에 매우 취약하므로 어떻게하면 조금 더 안전하게 사용자의 소셜 로그인 정보를 다룰 수 있을까의 고민에서 나온 방식이 OAuth방식이다.

소셜로그인이 이루어 지는 과정을 간단하게 정리하자면 Client는 우리 서비스, Resource Server(& Authorization Server)는 Facebook, kakao, Google 등등의 소셜 서버, Resource Owner는 위의 서비스에 가입된 User라고 생각 했을 때 Client에서 미리 Resource Server에 등록해놓은 Uri에서 Resource Owner(유저)에게 Resource Server를 이용해 인증을 할 것인지 요청을 보낸다. 이때 유저가 Resource Server를 통해 본인 인증을 마치고나면 해당 uri로 Resource Owner의 정보가 Client측으로 넘어오고 이때 Client는 Resource Server의 유저정보라는 것을 알 수 있는 Client id와 Client secret, Athorization code(임시 인증 코드)를 Resource Server의 Authorization Server에 인증함으로 access token을 받을 수 있다.

OAuth를 이용하는 목적은 API를 제어하기 위한 것.

조금 더 자세하게

1. Client

우리 서비스. 일반적으로 웹 또는 모바일 애플리케이션을 말하고, 클라이언트는 사용자 인증을 위해 소셜 미디어 플랫폼 (Resource Server)과 상호 작용한다.

2. Resource Server

Facebook, Kakao, Google와 같은 소셜 플랫폼. Resource Server는 사용자 데이터 및 인증 서비스를 제공하는 서버이다.

3. Authorization Server

OAuth 2.0 프로토콜을 사용할 때 Authorization Server는 Resource Server의 인증,인가를 담당하는 서버라고 생각할 수 있다. Authorization Server에서 사용자의 인증을 처리하고 클라이언트에게 액세스 토큰을 제공한다.

4. Resource Owner

소셜 플랫폼 (Resource Server)에 가입한 사용자. 자신의 소셜 계정을 통해 다른 서비스 (클라이언트)에 로그인하려는 사용자이다.

순서대로 자세히

1. 로그인 요청

클라이언트 (Client)에서 제공하는 소셜로그인 버튼을 클릭하면 클라이언트는 Resource Server (소셜 플랫폼)로 사용자를 리디렉션한다.

2. 로그인 인증 페이지 제공

사용자 (Resource Owner)는 Resource Server (카카오톡 같은 소셜)에서 로그인 또는 권한 부여 프로세스를 완료한다. 이 프로세스에서 소셜 계정으로 로그인하는 단계가 포함된다. 단 정보는 아래 단계에서 전달된다.

3. Authorization Code 발급 받기

Resource Server는 클라이언트로 리디렉션하며, 클라이언트가 미리 등록한 콜백 URI로 사용자 정보와 임시 인증 코드(Authorization Code)를 전송한다.

4. Authorization Code과 access token 교환 1

클라이언트는 Authorization Code를 사용하여 Authorization Server에 액세스 토큰 요청을 보냅니다. 이때 클라이언트는 Authorization Code와 함께 전달받은 Client ID 및 Client secret으로 Resource Server의 유저로 부터 받은 정보가 맞는지 자신을 인증한다.

5. Authorization Code과 access token 교환 2

Authorization Server는 클라이언트를 확인하고 유효한 경우 액세스 토큰을 발급한다.

6. access token으로 리소스 접근 (로그인 성공)

클라이언트는 액세스 토큰을 사용하여 Resource Server에서 사용자 데이터를 요청하고, Resource Server는 액세스 토큰을 확인하여 요청을 승인하고 사용자 데이터를 제공한다. 이때 제공되는 사용자 데이터는 Scope로 정의될 수 있다.

추가

access token은 인증 기간이 짧아서 기간이 끝나면 refresh token을 이용해 다시 발급해줘야한다. 이 때 서비스마다 refreshing방법이 다르니 이용하고자하는 소셜 플랫폼의 공식문서를 참고해야한다.

알고 있어야하는 개념

1. OAuth (Open Authorization): OAuth는 사용자가 다른 애플리케이션 또는 웹 서비스로부터 권한을 부여받는 인증 및 권한 부여 프로토콜. 소셜 로그인은 OAuth를 기반으로 작동하며 사용자는 소셜 미디어 플랫폼 (예: Facebook, Google, Twitter)에서 제 3자 애플리케이션에 권한을 부여한다.

2. 소셜 미디어 API: 소셜 미디어 플랫폼은 OAuth 2.0를 지원하는 API를 제공한다. 이러한 API를 사용하여 사용자 데이터를 가져오고 인증 및 권한 부여 프로세스를 처리할 수 있다. 각 소셜 미디어 플랫폼은 고유한 API 및 개발자 도구를 제공하며, 이를 이해하고 사용해야 한다.

3. 클라이언트 백엔드 구조: 소셜 로그인 구현에는 클라이언트 애플리케이션 (웹 또는 모바일) 및 백엔드 서버 간의 원활한 통신이 필요하다. 클라이언트는 사용자에게 소셜 로그인 버튼을 제공하고, 백엔드 서버는 소셜 미디어 플랫폼과의 상호 작용을 처리한다.

4. 사용자 데이터 관리: 소셜 로그인 후에는 사용자 데이터를 관리해야 한다. 이 데이터는 사용자의 프로필 정보, 이메일 주소, 프로필 사진 등을 포함하며, 이를 신중하게 저장하고 활용해야 한다. 사용자 개인정보 보호 및 데이터 활용에 관한 규정 및 정책을 준수해야 한다.

5. 보안: 소셜 로그인 구현 시 보안은 핵심 고려 사항 중 하나이다. OAuth 프로토콜 및 사용자 데이터 처리를 안전하게 관리해야 한다. SSL/TLS를 사용하여 데이터 통신을 암호화하고, 사용자 데이터에 대한 접근 권한을 엄격하게 관리해야 한다.

6. 사용자 경험: 사용자의 편의성과 안전을 고려하여 소셜 로그인 버튼을 적절한 위치에 배치하고, 사용자에게 필요한 권한을 요청할 때 명확하고 사용자 친화적으로 설명해야 한다.

소셜 로그인을 구현하기 전, 위의 개념을 숙지하고 특정 소셜 플랫폼의 API를 이해하는 것이 중요! 소셜마다 리프레쉬 토큰 발급 방법과 구현 과정이 다르니 꼭 공식 문서를 참고하며 구현하도록 한다.

추가적으로 공부하면 좋은 내용

• 왜 access token을 바로 주는 것이아니라 Authorization code발급 과정을 거칠까?
• 소셜로그인 구현시 백엔드와 프론트엔드의 역할?
  이 방법은 구현하는 사람마다 너무 달라서 처음 구현할때 너무 헤맸는데 잘 정리된 게시글을 찾았다.