-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
해결됨
Authorization server 에서 localhost 를 사용하지 못하는 이유가 있을까요?
23.06.04 17:12 작성 23.06.04 17:46 수정 조회수 414
0
안녕하세요.
말씀해주신 대로 호스트를 localhost 로 사용하는 경우에는 17::24 화면처럼 세션을 찾을수 없는 문제가 있는것을 확인하였습니다.
redirect uri 를 모두 localhost 로 세팅 하였을때도 문제가 있는것을 확인했는데요, 그렇다면 authorization server 에서 로그인 성공시 host 가 localhost 이면 별도로 쿠키에 세팅을 해주지 않는다는 의미인가 해서 보니 권한 동의 이후 /oauth2/authorize 로 submit 을 할 Authorization Server 의 OAuth2AuthorizationEndpointFilter.java 에서 187 line 의 sessionAuthenticationStrategy 에서는 정상적으로 세션을 세팅하는것 같아보였습니다. (아래는 세팅되는 OAuth2AuthorizationServerConfigurer.java 282line. 의 lamda 로직입니다
그렇다면 Client 쪽에서 같은 localhost 의 쿠키 id를 가져와서 사용하지 못한다는 말 같은데, 제가 빠뜨린 부분이 있는지 확인부탁드리겠습니다.
답변을 작성해보세요.
0
정수원
지식공유자2023.06.05
네
강의에서 설명하는 부분은 localhost 로 redirect_url 로 설정 할 경우 인가서버에서 차단하기 때문에 localhost 가 아닌 도메인이나 아이피로 설정해야 한다는 것을 설명하고 있는 것입니다.
일단 세션 문제는 클라이언트는 스킴이 localhost 이고 인가서버는 127.0.0.1 로 다시 redirect_uri 로 응답하기 때문에 생긴 현상이고 클라이언트와 인가서버가 동시에 localhost 로 동일한 스킴을 사용한다 하더라도 인가서버쪽에서 차단하기 때문에 아예 처음부터 도메인 혹은 아이피로 설정 및 통신해야 한다는 의미로 설명하고 있다고 보시면 됩니다.
클라이언트는 최초 세션이 발급되었을 떄 해당 세션으로 서버 쪽에 어떤 값을 저장했는데 인가서버에서 redirect_uri 응답으로 클라이언트가 다시 서버에 요청을 하는 시점에서는 인가서버에서 응답한 스킴정보와 달라서 이전의 세션이 아닌 새로운 세션이 혹은 세션쿠키 없이 접속하기 때문에 이전의 세션에 저장했던 값들을 참조할 수 없게 됩니다.
요점은 인가서버와 통신할 때 가급적 localhost 를 사용하지 말라는 의미입니다
램쥐뱅
질문자2023.06.06
안녕하세요.
말씀해주신 localhost 의 내용의 취지와는 다르게 localhost 를 사용하는 것이 문제가 아니고 인가서버와 클라이언트가 같은 host 주소를 사용할때 생기는 session id 갱신에 대한 문제가 의심이 됩니다.
정리하자면 개발환경처럼 authorization server 와 client 두가지가 같은 host 주소를 사용하고 있는 상황일때 클라이언트쪽에서 사용하려고 생성했던 session id 를 인가서버의 login 동작에서 (보통 보안상 문제로) 기존 ssesion id 를 사용하지 않고 새로 response 되는 session id로 덮어 써버립니다. 결론적으로는 나중에 클라이언트로 redirect 시켰을때 클라이언트는 처음에 생성했던 session id 에 맞는 session 이 없게되어 버립니다.
결론적으로 인가서버와 클라이언트 서버가 host 주소를 같이 사용하고 cookie 에 session id 를 저장하는 방식을 사용하는 개발환경의 방식에서는 localhost 의 주소를 사용하는것이 문제가 아니라 인가서버와 클라이언트 서버의 host 주소가 같다는 것이 문제의 원인으로 생각되며 인가서버와, 클라이언트 서버의 host 주소를 127.0.0.1 로 동일하게 사용한다면 localhost 를 사용하지 않더라도 같은 문제가 발생 할 것입니다.
때문에 강의에서 제안된 개발환경에서는 인가서버를 localhost, 클라이언드를 127.0.0.1 (혹은 그반대로) 서로의 host 주소를 다르게 해주어야 정상적으로 작동하게 되는것이 아닐까 생각합니다.
정수원
지식공유자2023.06.08
음
제가 테스트 한 것과는 반대되는 내용인데요..
아시겠지만 클라이언트 즉 브라우저 요청 시 도메인이 다르면 서버에서는 다른 세션으로 받아들입니다
클라이언트가 처음 인가서버로 임시코드를 요청할 때 클라이언트의 서버를 통해 백엔드에서 REST 로 통신하게 되는데 이때 클라이언트 서버에 생성된 세션은 localhost 도메인으로 생성되었습니다 그리고 클라이언트의 코드 요청을 처리한 인가서버가 127.0.0.1 로 302 응답을 하였다면 클라이언트는 127.0.0.1 로 다시 클라이언트 서버에게 재 요청을 하게 되는데 이 때는 이전의 localhost 에서 생성되어 있는 세션과 동일하지 않게 됩니다
왜냐하면 도메인이 다르기 때문에 당연한 현상입니다
제가 판단할 때는 박주성님이 클라이언트와 인가서버와의 통신과정에서 발생하는 세션을 클라이언트 내에서가 아니라 인가서버 세션과 연결짓는 것 같아 보이는데 해당 주제는 인가서버 세션과는 아무런 상관이 없습니다
처음 클라이언트의 요청으로 생성된 도메인의 세션과 두번째 요청으로 생성된 도메인의 세션이 서로 다르기 때문에 발생한 이슈이고 세션을 생성하는 주체는 클라이언트 서버이며 인가서버와는 상관이 없음을 이해하시면 될 것 같습니다
램쥐뱅
질문자2023.06.09
안녕하세요.
네 도메인이 달라서 생기는 세션 문제는 말씀해주신 내용으로 인지하고 있으며, 인가서버와 클라이언트의 세션에 대해서 말씀드린 내용은 아닙니다.
제가 오해를 했을 수 있을 내용이지만, 강의 내용과 답변해주신 내용으로 봤을때 localhost 라는 이름의 호스트 주소를 사용하는것 자체가 문제라는 내용으로 이해가 되어 말씀드린 내용입니다.
제가 댓글로 말씀드리고 확인하고자 했던 내용은 localhost 호스트명을 사용하던 127.0.0.1 를 사용하던 인가서버와 클라이언트는 서로의 호스트주소가 다르기만 하면 정상 작동 한다는 내용이였습니다.
org.springframework.security.web.authentication.session.ChangeSessionIdAuthenticationStrategy.java 의 정책으로 인해 생기는 문제인점을 명확하게 하고자 하는 의도였습니다.
위 정책때문에 인가서버와 리소스서버를 같은 도메인으로 사용하려고하면 문제가 생깁니다. (리소스 서버쪽에서 authorize_request_not_found: 초기에 cookie 아이디에 관련된 세션정보를 찾을수 없기때문)
그리고 localhost 가 문제였다면 keyclock 자체도 localhost 로 띄어서 사용했기때문에 문제가 있었어야 했다고 생각됩니다.
혹시나 제가 놓친 부분을 말씀해주시면 다시 한번 생각해보겠습니다.
답변 감사드립니다.
답변 1