인프런 커뮤니티 질문&답변
작성한 질문수
회원정보를 조회하는 API서버가 따로 있을때 로직 분리
작성
·
356
0
웹앱이 API에 요청을 할때도 올바른 대상이 요청하는게 맞는지 별도의 검증이 필요하지만
우선 그건 무시하고 순수히 웹앱의 유저 인증만 생각했을때의 이야기입니다..
프론트 역할을 하는
html, css, (바닐라js or jQuery) + spring boot(thymeleaf, spring security) 웹어플리케이션 프로젝트가 있고
회원이 있는지 조회할 수 있는 API 서버(DB와 연결된 spring boot)가 별도로 존재했을때
어떤 프로젝트에 어떤 식으로 시큐리티 및 토큰생성 세팅을 해야할지 감이 잘 오지 않습니다..
제가 구현하고자 하는건 회원/비회원에 따라
페이지를 동적으로 바꾸거나 (로그인이 로그아웃으로 바뀐다든지)
페이지에 접근을 못하게 하려고 합니다 (마이페이지)
제 생각에는 구현내용 둘 다 API를 굳이 갈 필요가 없기 때문에 웹앱단에서 검증이 이루어져야 할 것 같은데 맞을까요..?
API는 회원 유무를 조회한 뒤, 존재하는 경우 단순히 유저정보(or 아예 토큰을 만들어서 넘긴다..?)를 웹앱에 넘겨주는 것까지가 역할이고, 따라서 Spring Security는 여기서 필요하지 않다
웹앱 프로젝트에 스프링 시큐리티 설정을 한 뒤, 스프링부트단에서 API로부터 전달받은 토큰, 혹은 유저정보를 가지고 인증을 처리한다 (하지만 어떻게..?)
이런 흐름이 맞는지 모르겠습니다..
답변 2
0
API 서버에서 회원유무를 조회하는 부분을 인증 단계 없이 어떻게 처리할 것인지 궁금합니다.
일반적으로 회원 유무를 조회하기 위해 스프링 시큐리티의 기능이 필요한 것이고 (물론 단순히 아이디가 존재하는지만 확인한다 하더라도) 그리고 나서 패스워드 검증이나 기타 추가적인 인증에 필요한 검증 요소가 있을 수 있는데 이런 과정들이 시큐리티의 틀 안에서 통합적으로 이루어지는 것이 더 좋은 설계인 것 같은데 저렇게 서버를 나누는 특별한 이유가 있을까요?
시큐리티는 회원과 비회원의 통합적인 구조를 가지고 움직이기 때문에 전체적인 흐름에 있어서 인증과정을 시큐리티와 비 시큐리티로 구분해서 처리한다는 것이 좋은 설계인지 잘 모르겠네요
시큐리티가 적용된 상황이라 할지라도 회원과 비회원에 따라 여러 기능들을 구분해서 처리가 가능합니다.
제가 잘 이해 하지 못한 부분이 있을까요?
0
안녕하세요, 인프런 AI 인턴입니다.
암차님의 질문에 대한 답변입니다.
웹 애플리케이션에서 유저 인증 및 페이지 접근 제어를 구현하는 경우, 일반적으로 Spring Security를 활용하여 인증과 인가 메커니즘을 설정합니다. 스프링 시큐리티를 이용하면 다양한 인증 방식을 구현할 수 있으며, 이를 통해 보안 장벽을 만들고 접근 제어를 처리할 수 있습니다. 여러분의 상황을 고려했을 때의 흐름은 다음과 같이 추천드립니다:
API 서버는 유저 정보를 검증하고, 유효한 경우 유저 정보나 생성된 토큰을 웹 애플리케이션에 반환합니다. 이 과정에서 Spring Security를 적용할 필요는 없으며, 단순히 API의 역할로 충분합니다.
웹 애플리케이션 측에서는 Spring Boot와 Spring Security를 설정하여 API 서버로부터 반환받은 토큰 또는 유저 정보를 기반으로 인증을 수행합니다. 이때,
UserDetailsService를 사용하여 유저 정보를 로드하고 인증 절차를 진행할 수 있습니다. 스프링 시큐리티 설정 예제는 다음 문서를 참고하시기 바랍니다: Spring Security reference documentation 및 Spring Security Reference Guide.페이지 접근 권한은
SecurityFilterChain을 통해 핸들링하여, 특정 페이지나 API 엔드포인트에 대한 접근을 인증된 유저에게만 허용하도록 설정할 수 있습니다. Spring Boot documentation에 나온SecurityFilterChain설정 방법을 참고하십시오.
구현하고자 하는 로그인 상태에 따른 페이지 동적 변경과 접근 제한은 위에서 언급한 인증 프로세스 후 스프링 시큐리티가 제공하는 권한에 따라 처리할 수 있습니다. 스프링 시큐리티와 템플릿 엔진(예: Thymeleaf)을 함께 사용하여 사용자 로그인 상태에 따라 보이는 화면을 변경할 수 있습니다.
투명하고 탄탄한 인증 시스템을 구축하기 위해 위 가이드라인을 따라가시면 조금 더 명확한 방향을 설정하실 수 있을 것입니다.
안녕하세요 프로젝트때문에 답변이 많이 늦어졌습니다
html+css+js로 구성된 프론트엔드와 자바로 구성된 백엔드가 한 프로젝트에 같이 있는 상황이었고,
모든 요청을 백엔드를 통한 뒤 그 백단에서 별도의 API 서버로 요청을 보내는 구조였습니다. 거기에 인증서버도 별도로 있었구요..
회사 대부분의 프로젝트가 저런식으로 일단 동일 어플리케이션 안의 Back단으로 요청을 보내면, Back단에서 다시 별개의 API를 호출하는 구조로 되어있어 저것도 동일하게 만들게 되었습니다..
또 웹앱 컨트롤러단에 @ResponseBody가 붙은 메소드와 일반 html을 내려주는 메소드가 혼재되어 있었고,
어떤 페이지는 타임리프를 통해 서버사이드에서 렌더링을 진행하고, 또 어떤 부분은 ajax요청을 통해 클라이언트단에서 렌더링을 진행하는 등 뭔가가 깔끔하게 떨어지지 않는 상황이었습니다.
form전송이나 js ajax를 통해 동일 어플리케이션 내 Back단 컨트롤러 호출
Back단에서 API서버로 Rest요청
API서버에서 토큰이 유효한지 인증서버에 확인요청
문제없으면 요청한 값 웹앱에 리턴, 문제있으면 미리 약속된 HttpStatus 코드를 웹앱에 전달
웹앱에서 HttpStatus를 보고 문제가 있으면 상황따라 토큰을 만료시키거나 인증서버로 재발급을 요청
재발급 받은 토큰으로 API에 재요청
최종적으로는 이런 식으로 구현하게 되었습니다.
구현을 하면서 느낀 점은 토큰을 통한 인증 방식의 경우
리액트같은 온리 프론트만 있는 프로젝트에서 바로 API에 요청을 하거나
스프링을 쓰더라도 컨트롤러가 RestController로서 API로부터 JSON을 받아 그 데이터만 내려주는 형태로
서버사이드 렌더링을 쓰지 않는 경우에 적합한 방식인 것 같다는 생각이 들었는데 제 생각이 맞..을까요..?