Security

이 포스팅은 (1) 스프링 시큐리티 - 알아두어야 할 세 가지 개념과 (2) 스프링 시큐리티 - 스프링 시큐리티 세션에서 이어지는 글입니다. 서론 이전 글에서 세션은 하나의 서버를 운용할 때를 상정하고 나온 개념이라는 전제로 세션을 설명했었습니다. 하지만 서버의 규모와 트래픽이 나날이 갈수록 커지면서 서버를 여러대로 분산시켜야 하는 경우가 비일비재해졌습니다. 서버를 여러대로 분산시킨다는 것은 곧, 여러 대의 서버에서 하나의 세션을 공유해야한다는 전제가 새로 만들어지게 되는 셈입니다. 이것을 어떻게 해결할 수 있을까요? 물론, 세션을 관리하는 인메모리 DB를 가지는 중앙집중식 서버를 하나 두거나, 관련 인증 서버 체계를 두거나 하면 될 것입니다. 하지만 서버를 더 늘려야 하는데 인증 서버를 더욱 더 늘려야..

이 포스팅은 (1) 스프링 시큐리티 - 알아두어야 할 세 가지 개념에서 이어지는 글입니다. 서론 세션은 다들 아시다시피 본디 하나의 서버를 운용할 때를 상정하고 나온 개념입니다. 다시 말씀드립니다. 프론트엔드와 백엔드가 하나의 서버에 있을 때 세션을 보통 사용한다고들 말합니다. 저도 처음에 JWT같이 다른 인증 시스템을 만들어 볼 때 혼동이 왔었습니다. 요즘 프론트-엔드와 백-엔드의 서버를 나누다 보니 세션도 나누는 것인가? 하구요. 세션을 개발하기 전에 꼭 잊지 말아야 할 사항이 바로 본디 세션은 하나의 서버에서 운용하도록 설계가 되어졌다 입니다. 이 가정을 바탕으로 글을 쓰도록 하겠습니다. (당연하게도 지금은 여러 서버에서 세션을 운용하는 방법이 있습니다! 레디스같은 하나의 인메모리에서 세션을 관리한..

서론 스프링 시큐리티는 아무리 봐도 복잡하게 설계가 되어 있습니다. 각 단계를 추상화하고, 분리하다보니 중간에서 하는 일이 많아지고, 밖에서 접근하는 방법도 달라졌던 것 같습니다. Spring Security는 공부를 해보니 여전히 정말 쉽지 않은 스프링 모듈 중에 하나입니다. `Security`라는 단어에 걸맞게도 복잡하게 이루어진걸지도 모릅니다. 아무튼 공부를 하면서 제가 알아낸 정보들, 공부했던 정보들을 바탕으로 포스팅을 해보려 합니다. 또, 실전으로 연습했던 코드도 포함해서요. 이번 포스팅에서는 일단 간단하게 Security에서 저희가 짚고 넘어가야할 부분들에 대해서 적어보겠습니다. SecurityContext 시큐리티는 시큐리티 모듈의 `SecurityContext` 안에서 인증/인가 정보가 다..

아래 글은 RFC 7519 를 기반으로 작성되었습니다. 서론 세상에는 두 태양이 공존할 수 없다고 하죠... 하지만 인증 세계에는 아직 두 개의 태양이 공존(?)하고 있습니다. 하나는 세션이고 하나는 JWT죠. 필자가 알기로 세션의 개념이 먼저 나왔다고 알고 있습니다. 세션은 쿠키라는 저장소에 담아서 상태를 저장하는 개념으로 나왔었죠. 하지만 이는 독자분들이 아시다시피, HTTP는 무상태라는 개념과 상충하는 바임을 쉽게 알 수 있습니다. HTTP가 무상태이다보니, 서로 간의 상태를 저장해두고 확인하고 싶었겠죠. 저라도 서비스를 저장할 때 이런 정보를 저장해놓고 사용하고 싶을 겁니다. 하지만 상태를 저장하다보니, 세션이 많아질수록 지연 시간이 늘고 성능에 의존하는 일이 잦아졌습니다. 이를 어떻게 해결해야할..

서론 요즘 부트캠프의 프로젝트를 진행한다고 정신이 없습니다... 그래서 블로그를 작성하던 습관도 다 없어지고, 진행하고 있었던 개인 사이드 프로젝트도 주춤했죠. 하지만 부트캠프의 프로젝트를 진행하면서 얻었던 것이 정말정말 많았습니다. 12월이 되면서, 개발 스터디에 대한 마음을 다잡을 겸해서 얻었던 것들을 이제라도 하나하나씩 써 나가볼 예정입니다. 내용 본 글은 CORS에 대한 지식을 어느정도 알고 계신다는 하에 작성되었습니다. CORS 설정에 앞서서, 두 가지를 설명드리고자 합니다. 첫번째는 Spring Web에서의 CORS 설정이고, 두번째는 Spring Security에서의 CORS 설정입니다. 본 글을 보시는 분들은 알고 계시다시피 Spring Web과 Spring Security는 큰 Sprin..