모바일에선 왜 세션보다 토큰을 선호할까? / 쿠키 / 토큰

오늘 한 일

배운 내용

모바일에선 왜 세션보다 토큰을 선호할까?

세션은 보편적으로 쿠키와 묶어 사용하는 경우가 많다. 그러나, 네이티브 앱의 경우, 브라우저를 사용하지 않기 때문에 쿠키 동작이 수행되지 않는다.

세션과 토큰을 비교할 때는 클라이언트로 무엇을 쓰는지 비교할 수도 있지만, 인증 정보를 세션(저장소)에서 관리할지, 암호화해서 토큰에 넣어 관리할지를 비교하는 것이 더 올바르다.

JESESSIONID

서블릿 컨테이너에서 생성하는 쿠키. 웹서버가 세션 관리로 쿠키를 사용하면 JSESSION라는 쿠키를 만들어 클라이언트에 보낸다

톰캣 컨테이너를 2개 이상 사용하면 세션을 유지할 수 없기 때문에 세션 클러스터링 환경을 구축해야 한다

쿠키

데이터를 브라우저측에 저장한 후 다시 데이터를 받아오는 기술을 말한다. 헤더 영역에 들어있고, <이름>=<값> 형태의 문자열 꼴을 가진다.

1. 쿠키 전달은 서버가 클라이언트 요청에 응답할 때 전송하는데, Set-Cookie라는 응답 헤더에 브라우저가 수신해야 할 쿠키 정보를 명시하도록 한다.

• 이때 쿠키를 얼마나 오래 유지할지 명시해야 한다. Expires나 Max-Age 속성을 사용한다

2. 브라우저는 해당 쿠키를 컴퓨터의 HDD에 저장하고, 동일한 서버에 요청할 때 저장해 놓은 쿠키를 Cookie라는 요청 헤더에 실어 보낸다.

Cookie 요청 헤더는 여러 쿠키를 ;로 구분해 나열한다

• Cookie: <이름>=<값>; <이름>=<값>; <이름>=<값>

쿠키는 HTTP 클라이언트인 브라우저에서만 사용 가능하다.

• curl을 사용하면 Set-Cookie 응답 헤더에 뭐가 들어있다고 해서 HDD에 저장하거나, 매 요청마다 쿠키를 넣거나 하진 않는다.

유효 기간이 별도로 명시되지 않은 쿠키를 세션 쿠키(session cookie)라고 부르는데, 브라우저 세션이 종료되면 만료된다.

쿠키는 유실 / 변조 / 도난 등 보안이 약하기 때문에 다음 속성 사용이 권장된다

• Secure : https 프로토콜 상에서만 서버로 쿠키를 보낸다
• HttpOnly : 브라우저 / 서드파티에서 JS로 쿠키에 접근할 수 없다.

참조

• https://www.daleseo.com/http-cookies/#google_vignette

Refresh Token

토큰 인증방식은 탈취당할 경우 보안에 취약하다. 이를 해결하기 위해 유효기간을 짧게 유지할 수 있는데, 이건 자주 로그인해야 하므로 유지 입장에서 불편하다.

Refresh Token은 두 마리 토끼를 한 번에 잡는 전략이다.

1. Refresh Token은 Access Token과 똑같은 형태의 JWT 토큰이며, 최초 로그인 완료시 유효 기간이 짧은 Access Token과 유효 기간이 긴 Refresh Token을 각각 발급한다.
2. Access Token이 만료되면, 클라이언트는 서버에게 Access Token을 재발급 요청하는데 이때 Refresh Token을 같이 보낸다.
3. 만약 Refresh Token이 만료되지 않았으면 Access Token을 새로 발급하며, 만료되었을 경우 다시 로그인을 요구한다.

출처 : https://tansfil.tistory.com/60?category=475681

참조

• https://tansfil.tistory.com/60?category=475681

각 인증방식

느낀 점

오늘 사이드를 같이 하기로 한 분과 내가 최근에 짠 코드를 보면서 간단한 코드 리뷰를 했고, 코드 컨벤션 방식에 대해서 이야기를 했다. 최근에 클린 코드나 과도한 객체지향 이런 것들에 대해 꽤 회의감을 가지고 있었는데, 다른 한 편으로는 이번 기회에 한 번 해보는 것도 나쁘지 않겠다는 생각이 든다.

물론, 현업에서는 그런 것에 시간을 많이 쓰진 않겠지만 현재 삽질을 많이 해두어야 나중에 갔을 때 의식적으로 적용할 수 있고 긍정적인 효과를 낳을 수 있지 않을까? 하는 생각이 든다.

팀원 분은 불변성의 장점에 대해서 계속해서 말씀 하셨는데, 솔직히 나는 공감하지 못했다. 그래서 계속 방어적인 스탠스를 취했다. 그러나 지금 와서 생각해 보니 그럴 필요까진 있었나? 하는 생각이 든다. 내가 겪어보지 못한 걸 겪으셨으니 그런 것이실테고, 내가 아직 겪어보지 못했기 때문에 방어적인 태도를 취했던 건, 이번에 겪어보면 확실하게 장단점에서 좀더 알 수 있게 되지 않을까? 하는 생각이 든다.

뭔가 내가 처음에 팀을 모집할 때 '클린코드에 대해서 크게 신경 쓰지 않겠어!'라는 생각으로 뽑았기 때문에 그 생각이 내 행동을 지배한 건 아닐까? 하는 생각이 든다.

요즘 들어 느끼는 건데, 무조건 비즈니스를 위한 기술을 따르는 것도 100% 옳을까? 하는 생각도 든다. 어쨌든 개발자라면 기술에 대한 목마름을 어느정도 가지고 있는 사람들이 많고, 그것을 해결시켜 주는 것이 건강한 팀을 만들고 더 생산력도 늘어나지 않을까 하는 생각이 든다.