관리자 페이지와 사용자 페이지 상호 이동 가능성

[rlajm1203]

EEOS 3.0

EEOS 3.0에서 관리자 기능이 추가됨에 따라서, 관리자 페이지가 새로 생겼습니다.
또한 고정 사용자인 관리자 또한 생겼습니다.
-> 관리자 페이지, 관리자 계정 추가 (로그인 기능 포함)

문제 상황

관리자 로그인 기능에서, 토큰을 생성할 때 일반 사용자와 똑같은 구조로 토큰을 생성하여 보내고 있습니다.
또한, DB에 관리자 계정이 없을 경우 BE 서버 실행 시 자동으로 관리자 계정이 생성되도록 하고 있습니다. (관리자 ID와 PW는 정적)

이때 문제가 발생합니다. 프론트 페이지에서는 로그인 성공시 메인 화면으로 넘어가는데 이때 메인 화면 이동 조건이 로컬 스토리지에 저장된 토큰의 유무입니다.

1. 토큰이 존재한다 -> 페이지 이동
2. 토큰이 존재하지 않는다. -> 페이지 이동 불가

만약 일반 사용자가 사용자 페이지에서 로그인에 성공한 후, 브라우저의 주소창에 관리자 페이지의 주소를 입력하면 접속이 되는 것입니다.

일반 사용자가 관리자 페이지에 접속하는 것은 문제인가?

저는 문제라고 생각합니다. 일반 사용자와 관리자는 엄연히 권한을 다르게 부여받은 사용자입니다.

따라서 각각의 권한에 맞게 볼 수 있는 정보의 범위가 정해져 있습니다.

하지만 현 상황에서는 일반 사용자가 사용자 페이지에서 로그인에 성공한 후 관리자 페이지에 접속하면 메인 페이지 , 회원 관리 페이지 , 행사 생성 페이지 등 많은 페이지에 접근할 수 있는 상황입니다.

(행사 생성, 수정, 삭제 및 회원 관리 변경에 관한 동작은 서버 내부적으로 관리자일 때만 허용하게 해놓았습니다.)

어떻게 해결하나?

2기들이 생각한 방안

BlackCompany 2기 멤버들이 (@Daae-Kim @geongyu09 @rlajm1203) 생각한 첫 번째 방안으로는

토큰에 유효 범위를 지정해서 전달하는 것입니다. 토큰의 유효 범위(페이지의 범위(?))를 같이 전달하면, 프론트 측에서 이를 검사하여 페이지를 이동하거나 이동하지 못하게 할 수 있습니다.

하지만 이는 엄청 비효율적인 방법으로, 페이지를 이동할 때마다 토큰의 범위가 유효한지 체크를 해야 하므로 속도가 저하된다는 단점이 있습니다.

관리자 API를 만드는 등의 다른 방안도 생각해보았지만, 근본적인 원인인 페이지를 이동하는 것은 막을 수 없다고 생각하여 이렇게 디스커션 올려봅니다.

etc..

리눅스에서 파일 접근 권한이 rwx가 있는 것처럼 하위 레벨 권한을 가진 사용자가 상위 레벨 권한의 정보를 조회할 수 있도록 시스템 정책 상으로 설정하는 것도 생각해보았는데 어떻게 생각하시나요?

[kssumin]

토큰에 권한 정보를 같이 넣어서 발행하고 특정 api요청시에 be에서 권한을 확인하자

현재는 토큰에 memberId값만 전달하고 있는데요!
토큰에 권한(일반멤버, 어드민)을 같이 포함하는 건 어떠신가요??

지금은 @member 어노테이션을 통하여 로그인 한 유저인지만 판단하고 있지만
이를 @Admin과 같은 어노테이션을 통해서 특정 api는 관리자일때만 접근할 수 있도록 할 수 있을 것 같아요!!

물론 @Admin에서는 토큰 검사시에 어드민인지 확인하는 식으로요!

프론트에서 검사하는 방식

브라우저에서 접속하는 유저가 아니라 curl과 같은 요청으로 be에게 날린다면
이때는 관리자가 아닌 유저가 관리자 페이지에서만 확인할 수 있는 정보를 알 수 있다는 단점이 있을 것 같습니다.

따라서 관리자 관련 정보 요청 시 be에서 아예 막아서 정보를 전달하지 않아야 한다고 생각합니다.

[kssumin]

관련 코드 첨부

@Member 어노테이션이 있을 때 AOP를 통해서 토큰에서 memberId를 추출하는 코드

이와 유사하게 @Admin 어노테이션을 AOP를 적용해서 권한을 검사하면 될 것 같습니다.

[kssumin]

다시 읽어보니... 제가 말씀하신 걸 잘 못 이해한 것 같아 다시 답글을 답니다!

토큰에 유효 범위를 지정해서 전달하는 것입니다. 토큰의 유효 범위(페이지의 범위(?))를 같이 전달하면, 프론트 측에서 이를 검사하여 페이지를 이동하거나 이동하지 못하게 할 수 있습니다.

페이지 간의 이동

• 결국 유저는 페이지 단위로 이동을 하겠지만, 해당 페이지에서 관련 정보를 보려면 프론트가 서버에게 요청을 보내야만 합니다.
• 따라서 특정 유저만 할 수 있는 행위에 대해 요청이 들어올 때 서버는 그 api를 호출하는 사람이 적절한 권한을 가지고 있는지만 확인하면 된다고 생각합니다.
• 즉, "페이지" 단위로 생각하지 않아도 된다! 라는 생각입니다.

해당 토큰으로 갈 수 있는 페이지의 범위를 전달한다.

• 토큰의 payload에 페이지를 넘긴다면 프론트에서는 토큰을 해독할 줄 알아야 하는데, 그렇다면 secretKey를 중복해서 관리해야 하는 문제도 있을 것 같습니다.
• 또한, 프론트는 서버로부터 정보를 불러와서 잘 보여주는 것에 집중하는 역할이라고 생각하여 토큰을 추출하는 일을 프론트에게 넘겨서는 안 된다고 생각합니다.

따라서 기존처럼 admin인지 확인해도 된다고 생각합니다. 다만 인터셉터로 옮겨보는 게 어떤가요?

• 해당 API를 요청했을 때 적절한 권을 가지고 있는지만 백엔드에서 확인하면 되는데
• 이는 구현하신 코드처럼 service에서 admin인지 체크해도 된다고 생각합니다.

* 다만 이는 인터셉터 단에서 인가를 처리하는 게 더 좋아보입니다.

토큰의 payload에 역할을 추가하는 건 어떤가요?

• 지금은 토큰의 payload에 memberId 밖에 없어서 만약, 이 토큰으로 admin인지 인터셉터 단에서 체크를 하게 된다면
• 매 api 호출시 db와 connection을 해야하는 문제가 있을 것 같습니다.(이는 토큰을 사용하는 의미가 없다고 생각합니다.)
• 따라서 토큰의 payload에 역할을 추가하여 토큰의 장점 또한 같이 가져가는 게 좋을 것 같습니다!

[rlajm1203]

맞습니다! 저도 이번에 리크루트 코드를 분석하면서 알게된 건데, 토큰의 payload 부분에 권한까지 같이 넣어서,
필터 단에서 URI와 HTTP 메소드를 기준으로 네트워크 요청 필터링을 할 수 있더군요!

마찬가지로, 관리자 페이지에서 사용하는 API에 관해서 권한을 체크해서 페이지에 접근을 하지 못하도록 해도 될 것 같습니다!

근데 하지만 우려되는 점이 있습니다.. 바로 하나의 API를 관리자 페이지와, 사용자 페이지 두 곳에서 모두 사용하는 경우가 있다는 것입니다.

일단 이 문제를 해결하기 위해서..?

1. API 분리..?

관리자 페이지와, 일반 사용자 페이지에서 공통적으로 사용하는 API가 존재할 것입니다.
예를 들어, 행사 리스트 조회와 같은.. 이러한 API에 대해서 일반 사용자 또는 관리자를 기준으로 필터링을 할 수 없을 것 같아서 관리자용 API와 일반 사용자용 API로 분리를 해야한다고 생각했습니다!

2. 하지만 관리자용 API와 일반 사용자용 API를 분리하는 것도 문제가 있습니다.

행사 리스트 조회와 같은 경우에는, 응답의 결과가 동일합니다. 일반 사용자 페이지에서 행사 리스트와, 관리자 페이지에서 행사 리스트 조회는 결국에는 같은 결과를 보여주는데 동일한 결과의 응답을 반환하는 API 이지만 굳이 분리를 해야하나 라는 생각도 듭니다.
우리가 코드 및 클래스를 작성할 때 잘 작성해서 다른 곳에서도 재사용할 수 있다면 무척 편리한 것처럼 API도 마찬가지라고 생각합니다.
잘 설계된 API를 하나 만들어 놓으면 이 API를 재사용 하는 방향이 좋다고 생각합니다.

3. 다른 방법이 없을까..?

일단 제가 지금까지 작성한 내용들은, 생각나는 대로 적어서 잘 정리가 되지 않았다는 점 양해 부탁드리겠습니다.
관리자용, 일반 사용자용 API를 굳이 분리하지 않고 기존 API를 재사용 하면서, 관리자 페이지 <-> 일반 사용자 페이지 상호 이동을 막는 방법이면 좋을 것 같다는 생각이 듭니다..!

[kssumin]

API 분리가 필요하지 않다라는 생각입니다. 이는 인터셉터를 통해서 인가 작업을 수행해야 한다고 생각합니다.

• 우선 기존처럼 @member를 통해서 로그인 한 유저인지 확인하고
• @PreAuthorize("hasRole('ADMIN')"*(security와 동일한 명칭을 가져왔습니다.) 처럼 어드민만 접근 가능한 API일 때는 토큰을 해독했을 때 유효한 권한을 가지고 있는지 확인하면 된다고 생각합니다.

어드민만 접근 가능한 API 일 경우

• @PreAuthorize("hasRole('ADMIN')" -> 유효한 admin인지 확인
• @member -> 해당 유효한 어드민의 memberId 정보 가져오기

member, 어드민만 접근 가능한 API 일 경우(행사 리스트 조회)

• @member -> 접근한 멤버의 memberId 정보 가져오기