OAuth2 Code Grant 방식의 동작 순서
- 로그인 페이지
- 성공 후 코드 발급 (redirect_url)
- 코드를 통해 Access 토큰 요청
- Access 토큰 발급 완료
- 유저 정보 획득 완료
JWT 방식에서 OAuth2 클라이언트 구성시 고민점
JWT 방식에서는 로그인(인증)이 성공하면 JWT 발급 문제와 웹/하이브리드/네이티브앱별 특징에 의해 OAuth2 Code Grant 방식 동작의 책임을 프론트엔드 측에 둘 것인지 백엔드 측에 둘 것인지 많은 고민을 한다.
-
로그인(인증)이 성공하면 JWT를 발급해야 하는 문제
- 프론트단에서 로그인 경로에 대한 하이퍼링크를 실행하면 소셜 로그인창이 등장하고 로그인 로직이 수행된다.
- 로그인이 성공되면 JWT가 발급되는데 하이퍼링크로 실행했기 때문에 JWT를 받을 로직이 없다. (해당 부분에 대해 redirect_url 설정에 따라 많은 고민이 필요하다.)
- API Client(axios, fetch)로 요청을 보내면 백엔드측으로 요청이 전송되지만 외부 서비스 로그인 페이지를 확인할 수 없다.
-
웹/하이브리드/네이티브앱별 특징
- 웹에서 편하게 사용할 수 있는 웹페이지가 앱에서는 웹뷰로 보이기 때문에 UX적으로 안좋은 경험을 가질 수 있다.
- 앱 환경에서 쿠키 소멸 현상
위와 같은 문제로 OAuth2 Code Grant 방식 동작에 대한 redirect_url, Access 토큰 발급 문제를 어느 단에서 처리해야 하는지에 대한 구현이 많고 잘못된 구현 방법도 많이 있다.
프론트/백 책임 분배
-
모든 책임을 프론트가 맡음
프론트단에서(로그인 -> 코드 발급 -> Access 토큰 -> 유저 정보 획득) 과정을 모두 수행한 뒤 백엔드단에서(유저 정보 -> jwt 발급) 방식으로 주로, 네이티브앱에서 사용하는 방식
-> 프론트에서 보낸 유저 정보의 진위 여부를 따지기 위해 추가적인 보안 로직이 필요하다. -
책임을 프론트와 백엔드가 나누어 가짐: 잘못된 방식(대부분의 웹 블로그가 이 방식으로 구현)
- 프론트단에서(로그인 -> 코드 발급)후 코드를 백엔드로 전송, 백엔드단에서(코드 -> 토큰 발급 -> 유저 정보 획득 -> jwt 발급)
- 프론트단에서(로그인 -> 코드 발급 -> Access 토큰)후 Access 토큰을 백엔드로 전송, 백엔드단에서(Access 토큰 -> 유저 정보 획득 -> JWT 발급)
카카오와 같은 대형 서비스 개발 포럼 및 보안 규격에서 위와 같은 코드/Access 토큰을 전송하는 방법을 지양함.
- 모든 책임을 백엔드가 맡음
프론트단에서 백엔드의 OAuth2 로그인 경로로 하이퍼링킹을 진행 후 백엔드단에서(로그인 페이지 요청 -> 코드 발급 -> Access 토큰 -> 유저 정보 획득 -> jwt 발급) 방식으로 주로 웹앱/모바일앱 통합 환경 서버에서 사용하는 방식
-> 백엔드에서 JWT를 발급하는 방식의 고민과 프론트측에서 받는 로직을 처리해야 한다.
참고자료: 개발자 유미 스프링 OAuth2 클라이언트 JWT