들어가면서

JWT 방식에서 OAuth2로그인을 진행하자.

JWT 방식에서 OAuth2로그인 할 때 고민해야할 점

왜 고민해봐야 할까?

바로 "세션 방식에서 OAuth2 로그인"과 JWT에서의 로그인이 차이가 있기 때문이다.

jwt를 언제 발급할 수 있을까

하이퍼링크로 진행할 때

프론트엔드가 jwt를 전달 받을 수 없다.

• 사용자가 소셜 로그인을 진행하면 소셜 로그인 서비스는 미리 설정해둔 리다이렉트 URL 사용자를 보낸다.
• 이때 하이퍼링크로 작동되기 때문에 상태가 유지되지 않고 JWT를 받아서 저장하거나 사용할 수 없게 된다.

API Client로 요청을 보내면

• API 클라이언트를 통해 백엔드로 요청을 보내면 외부 서비스의 로그인 페이지를 볼 수 없다.

웹과 앱을 모두 지원할 경우

• 웹 페이지와 앱뷰의 차이로 안좋은 UX가 될 수 있다.
• 또한 앱 환경에서 쿠키가 소멸 될 수 있다.

여러 시나리오

프론트엔드와 백엔드의 책임 분배에 따라 경우를 나눴다.

모든 책임을 프론트가 맡음

• 프론트단에서 로그인, 코드 발급, Access 토큰, 유저 정보 획득까지 수행한다.
• 프론트는 백엔드에세 유저정보를 보낸다.
• 백엔드는 받은 유저 정보를 가지고 JWT를 발급한다.
• 주로 네이티브앱에서 사용한다.
• 백엔드가 받은 유저 정보의 진위여부를 위해 추가적인 보안 로직이 필요하다.

책임을 프론트와 백엔드가 나누어 가짐

경우 1

• 프론트에서 소셜 로그인을 진행하고 코드를 받은 후 백엔드에게 코드 전달 (API client방식)
• 백엔드는 받은 코드로 토큰을 발급받고 유저 정보를 획득한 후 jwt를 발급한다.
• jwt 발급이 간단해지지만 잘못된 방식이다.

경우 2. 프론트가 토큰을 발급

• 프론트가 토큰까지 발급하고 백엔드에게 API client방식으로 토큰 전송
• 백엔드에서 토큰을 가지고 유저 정보를 획득한 다음 jwt를 발급한다.
• jwt 발급이 간단해지지만 잘못된 방식이다.

왜 위 두가지 방법이 잘못됐을까?

엑세스 토큰과 코드를 전송하면 안된다.

• 보안이 안좋아진다.

모든 책임을 백엔드가 맡음

• 프론트에서 소셜 로그인 버튼를 통해 하이퍼 링크로 백엔드에세 API GET 요청을 보낸다.
• 백엔드 단에서 소셜 로그인을 진행하고 jwt를 발급한다.
• 이때 프론트가 하이퍼링크로 요청을 보냈다는 점을 주의하자.

우리는 어떻게 해야하나

모든 책임을 백엔드에서 맡아 진행하는 방식을 선택하자

마무리하면서

해내해내해내요~! 
알고리즘도 해내해내해내해내요~