[L.E.Assemble] 소셜 로그인 (카카오, 구글)

Spring Boot 환경에서의 OAuth2 소셜로그인

Spring Boot 구조로 구성된 L.E.Assemble 프로젝트에 적용한 OAuth2 소셜로그인에 대해 정리해봅니다.

 

 

 

📕 핵심 개념

 

OAuth2 (Open Authentication 2)

인증을 위한 표준 프로토콜
구글, 페이스북, 카카오 등에서 제공하는 Authorization Server를 통해 회원 정보를 인증하고 Access Token 발급
발급받은 Access Token을 이용해 타사의 API 서비스를 이용한다.

 

OAuth2 구성 요소

Client : 제 3의 서비스
Resource Server(자원 서버) : OAuth2 서비스를 제공하고, 자원을 관리하는 서버
Resource Owner(자원 소유자=사용자) : Resource Server의 계정을 소유하고 있는 사용자
Authorization Server(권한 서버) : Access Token, Refresh Token을 발급, 재발급 해주는 서버
Access Token : Authorization Server에게 발급받는 토큰, n시간, 1일의 유효기간
Refresh Token : Access Token보다 오래 가는 토큰, Refresh Token으로 Access Token을 갱신

Access Token이 만료되면 Refresh Token을 이용하여 갱신할 수 있지만 Refresh Token까지 만료됐다면 권한 서버에 사용자가 재로그인 해야 함

OAuth2 인증 종류

1. Authorization Code Grant Type : 권한 부여 코드 승인 타입
클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용됩니다. 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식

2. Implicit Grant Type : 암시적 승인
권한 코드 없이 바로 액세스 토큰을 즉시 발급받고 이를 인증에 이용하는 방식

3. Resource Owner Password Credentials Grant Type : 리소스 소유자 암호 자격 증명 타입
클라이언트가 인증서버의 ID,PW를 사용하여 액세스 토큰에 대한 사용자의 자격 증명을 교환.

4. Client Credentials Grant Type : 클라이언트 자격 증명 타입
클라이언트와 Resource Owner가 같을 때 사용, 추가적인 인증 없이 인증서버에서 토큰 발급

일반적으로 서버 사이드에서 1번 방식으로 사용하고 Authorization Code를 이용하여 권한서버에 토큰을 발급받는다. 토큰이 클라이언트로 전달되지 않기 때문에 보안에 좋다

그외 용어

(OAuth2) Service Provider : Kakao, Google, Facebook 등 OAuth2 소셜로그인 서비스 제공자

 

 

📄 로그인 시나리오

1. 클라이언트에서 서버에 로그인 요청을 한다.
2. 서버는 소셜로그인을 한다.
  2.1 서버는 인증서버에 Authorization Code를 요청한다.
  2.2 인증서버의 로그인 페이지로 이동
  2.3 인증서버는 사용자에게 ID,PW를 입력받고, 서비스 이용하기 위한 정보 제공 동의를 받음
  2.4 인증서버는 Authorization Code를 Redirect URI에 전달한다.
  2.5 서버는 전달 받은 Authorization Code를 기반으로 Access Token, Refresh Token(소셜 서버의 토큰)을 요청하고 받는다.
3. 서버는 사용자정보를 저장하고 로그인 처리를 한다.

 

✅ 적용 과정

구글

1. 구글 OAuth2 서비스 등록

1.1 OAuth2 동의화면 구성하기

1.2 사용자 인증 정보 구성하기

1.2.1 OAuth 클라이언트 ID

1.2.2 Redirect URI : http://localhost:8080/login/oauth2/code/google

 

카카오

1. 카카오 OAuth2 서비스 등록

1.1 카카오 로그인 기능 활성화

1.2 보안 탭에서 시크릿 키 발급

 

 

 

 

 

 

 

 

---

 

참고한 자료들

 

OAuth2 소셜로그인 출처 페이코 : https://developers.payco.com/guide/development/start

1. 시퀀스 상단: OAuth2.0 표준을 따르는 소셜 로그인 시퀀스 다이어그램
2. 시퀀스 하단: JWT 토큰의 유효기간이 끝났을 때의 시퀀스 다이어그램

1. 소셜 로그인 요청
2. 백엔드로 GET “/oauth2/authorization/{provider-id}?redirect_uri=http://localhost:3000/oauth/redirect”으로 OAuth 인가 요청
3. Provider 별로 Authorization Code 인증을 할 수 있도록 리다이렉트 (Redirect: GET “https://oauth.provider.com/oauth2.0/authorize?…”)
4. 리다이렉트 화면에서 provider 서비스에 로그인
5. 로그인이 완료된 후, Athorization server로부터 백엔드로 Authorization 코드 응답
6. 백엔드에서 인가 코드를 이용하여 Authorization Server에 엑세스 토큰 요청
7. 엑세스 토큰 획득
8. 엑세스 토큰을 이용하여 Resource Server에 유저 데이터 요청
9. 획득한 유저 데이터를 DB에 저장 후, JWT 엑세스 토큰과 리프레시 토큰을 생성
10. 리프레시 토큰은 수정 불가능한 쿠키에 저장하고, 엑세스 토큰은 프로트엔드 리다이렉트 URI 에 쿼리스트링에 토큰을 담아 리다이렉트 (Redirect: GET http://localhost:3000/oauth/redirect?token={jwt-token})
11. 프론트엔드에서 토큰을 저장 후, API 요청 시 헤더에 Authroization: Bearer {token}을 추가하여 요청
12. 백엔드에서는 토큰을 확인하여 권한 확인
13. 토큰이 만료된 경우, 쿠키에 저장된 리프레시 토큰을 이용하여 엑세스 토큰과 리프레시 토큰을 재발급

1. 소셜 로그인 요청
2. 백엔드로 GET “/oauth2/authorization/{provider-id}?redirect_uri=http://localhost:3000/oauth/redirect”으로 OAuth 인가 요청
3. Provider 별로 Authorization Code 인증을 할 수 있도록 리다이렉트 (Redirect: GET “https://oauth.provider.com/oauth2.0/authorize?…”)
4. 리다이렉트 화면에서 provider 서비스에 로그인
5. 로그인이 완료된 후, Athorization server로부터 백엔드로 Authorization 코드 응답
6. 백엔드에서 인가 코드를 이용하여 Authorization Server에 엑세스 토큰 요청
7. 엑세스 토큰 획득
8. 엑세스 토큰을 이용하여 Resource Server에 유저 데이터 요청
9. 획득한 유저 데이터를 DB에 저장 후, JWT 엑세스 토큰과 리프레시 토큰을 생성
10. 리프레시 토큰은 수정 불가능한 쿠키에 저장하고, 엑세스 토큰은 프로트엔드 리다이렉트 URI 에 쿼리스트링에 토큰을 담아 리다이렉트 (Redirect: GET http://localhost:3000/oauth/redirect?token={jwt-token})
11. 프론트엔드에서 토큰을 저장 후, API 요청 시 헤더에 Authroization: Bearer {token}을 추가하여 요청
12. 백엔드에서는 토큰을 확인하여 권한 확인
13. 토큰이 만료된 경우, 쿠키에 저장된 리프레시 토큰을 이용하여 엑세스 토큰과 리프레시 토큰을 재발급