-
로그인을 구현하시나요? 당장 Session사용을 멈추세요.프로그래밍 2024. 2. 15. 13:27
Session 객체에 로그인 정보와 유무를 담지 마세요. 빌드 후 다시 로그인 하시겠습니까?
웹 개발을 할때 가장 좋지 못한 계정 관리 케이스가 무엇이냐고 물어 본다면 아래와 같다.
"로그인 상태를 Session으로 처리하려고 할때이고 이 말은 빌드할때마다 로그인을 다시 해야 된다는 이야기다."
그럼 어떻게 처리해야 할까?
우리는 JWT가 있음을 알고 있다.
또한 JWT에 Claim정보를 넣을 수 있다는 것도 알고 있다.
Claim정보에 사용되는 것들은 대부분 규격화 되어 있다.
따라서 해당 규격에 맞게 JWT를 생성해서 Client(Browser)에서 보관하고 있어야 한다.
그것이 쿠키가 되었든 로컬스토리지가 되었든 말이다.
그럼 서버측에서는 어떻게 로그인 되었는지 알까?
JWT는 암호화되어 발행되고 해당 암호화된 Token은 서버측에서 해석할 수 있으며 동시에 같이 저장된 Claim정보도 알 수 있다.
즉, 수신된 Token이 해석된 User의 정보와 Claim 정보로 로그인을 처리하는 것이다.
(이 말은 Request가 수신된 상태에서 유저의 상태 정보를 조회해야 함을 의미한다.)
이미 대부분의 웹 프레임워크는 JWT와 통합되어 Authorize 처리를 제공해 주고 있다.
따라서, 임의로 로그인을 처리할려고 하지 마라.
JWT가 최선은 아니지만 적어도 빌드할때마다 로그인을 하게 만들지는 않을 것이다.
또한 JWT에 민감한 정보가 가서도 안되지만, 꼭 해당 정보가 조회되고 유지가 되어야 한다면 우리에게는 Redis가 있다.
JWT로 Client에서 로그인 되었음을 나타내고 Request가 발생하는 시점에 로그인 당시 조회된 민감정보가 Redis에 있다면 Redis에서 조회하면 될 것이다.
제발 Session으로 로그인 처리를 하지 말지어다.
'프로그래밍' 카테고리의 다른 글
ASP.NET MVC에서 ASP.NET CORE MVC + WEBAPI의 여정 - 파트2 (1) 2024.02.16 ASP.NET MVC에서 ASP.NET CORE MVC + WEBAPI의 여정 - 파트1 (0) 2024.02.15 ASP.NET 개발에서 DataTable은 만악의 근원입니다. (0) 2024.02.15 Why asp.net is too slow? compared to Java Spring. (0) 2024.01.09 DTO 클래스 대신 C# 레코드 사용 (0) 2023.12.03