|
| 1 | +- 세션과 토큰의 차이는? |
| 2 | + |
| 3 | + ### 세션 기반 로그인 |
| 4 | + |
| 5 | + 사용자의 로그인 정보를 서버에 저장해두는 방식 → **Stateful** |
| 6 | + |
| 7 | + 사용자가 로그인하면 해당 정보를 서버 세션 저장소에 저장해두고 세션 저장소의 식별자를 클라이언트에게 전달하여 식별자를 통해서 사용자를 식별한다 |
| 8 | + |
| 9 | + 로그아웃 시에는 세션 저장소에 있는 세션을 삭제한다 |
| 10 | + |
| 11 | + ### 토큰 기반 로그인 |
| 12 | + |
| 13 | + 사용자의 정보를 서버가 저장하지 않고 토큰을 통해 추적 → **Stateless** |
| 14 | + |
| 15 | + 사용자가 로그인을 하면 서버는 해당 사용자의 정보를 담은 토큰을 발행해서 클라이언트에게 전달한다 클라이언트는 받은 토큰을 저장하여 매 요청 보낼 때마다 토큰을 같이 보낸다 |
| 16 | + |
| 17 | + 로그아웃 시에는 토큰을 삭제하거나 블랙리스트로 관리하는 등의 조치 필요 |
| 18 | + |
| 19 | + ### 차이점 |
| 20 | + |
| 21 | + - 사이즈 |
| 22 | + - 세션은 세션ID만 실어보내면 되므로 네트워크 트래픽이 적음 하지만 토큰은 토큰의 발급시각, 만료시각, 토큰의 ID등 담겨있는 정보가 세션 ID에 비해 커서 네트워크 트래픽이 많이 필요 |
| 23 | + - 보안 |
| 24 | + - 세션은 모든 인증 정보가 서버에 있어서 보안에서 유리 |
| 25 | + - 해커가 세션 저장소의 식별자를 탈취하더라도 해당 세션을 무효하면 됨 |
| 26 | + - 토큰은 모든 인증 정보를 클라이언트가 가지고 있어서 탈취 당하면 해당 토큰이 만료되기 전까지는 할 수 있는게 없음 |
| 27 | + - 따라서 토큰 만료 기한을 짧게 두고 토큰 재발급을 위한 보조 토큰을 둬서 해결한 |
| 28 | + - 또한 토큰에서 Payload는 누구나 내용을 확인할 수 있으므로 들어갈 수 있는 정보에 한계가 있음 |
| 29 | + - 확장성 |
| 30 | + - 세션은 서버 여러 대를 사용할 때 세션 정보를 공유하는 추가 작업 필요 |
| 31 | + - 하지만 토큰은 필요 없음 → 확장성 높음 |
| 32 | + - 서버의 부담 |
| 33 | + - 세션은 서버가 세션 데이터를 직접 저장하고 관리해서 세션 데이터가 많아지면 부담 증가 |
| 34 | + - 하지만 토큰은 클라이언트가 인증 데이터를 가지고 있어서 서버의 부담이 준다 |
| 35 | + |
| 36 | + ### 실사용 |
| 37 | + |
| 38 | + 보안이 중요하다면 세션, |
| 39 | + |
| 40 | + 서버를 여러 개 사용한다면 토큰이 유리 |
| 41 | + |
| 42 | +- 엑세스 토큰과 리프레시 토큰이란? |
| 43 | + |
| 44 | + ## Access Token |
| 45 | + |
| 46 | + 서버에 접근 할 수 있는 권한을 증명하는 역할 |
| 47 | + 클라이언트는 API 요청 시 주로 HTTP Header의 Authorization 필드에 이 토큰을 담아 보냄 |
| 48 | + |
| 49 | + 권한을 증명하는 역할을 하기 때문에 탈취가 된다면 해커가 탈취한 토큰을 통해서 마음대로 요청을 보낼 수 있음 |
| 50 | + 따라서 주로 짧은 유효 기간을 가지고 Refresh Token과 함께 사용됨 |
| 51 | + |
| 52 | + ## Refresh Token |
| 53 | + |
| 54 | + 유효 기간이 짧은 access token이 만료 되었을 때 재발급 하기 위해서 필요한 토큰 |
| 55 | + |
| 56 | + 긴 유효 기간을 가지고 있음 |
| 57 | + |
| 58 | + **[ 사용 예시 ]** |
| 59 | + 1. 처음 로그인을 할 때 서버는 클라이언트에게 엑세스 토큰과 리프레시 토큰을 전달한다 |
| 60 | + 2. 서버는 리프레시 토큰만 저장하고 클라이언트는 둘 다 저장한 뒤에 요청이 있을 때마다 헤더에 담아서 보낸다 |
| 61 | + 3. 이 때 만료된 엑세스 토큰이 온다면 리프레시 토큰을 저장한 리프레시 토큰과 비교한 뒤에 일치한다면 다시 엑세스 토큰을 발급해준다 |
| 62 | + 4. 로그아웃하면 서버의 저장소에서 리프레시 토큰을 삭제하는 식으로 작동 |
| 63 | + |
| 64 | +- OAuth 1.0과 OAuth 2.0의 차이는? |
| 65 | + |
| 66 | + ### OAuth 1.0 |
| 67 | + |
| 68 | + 초기 OAuth로 보안은 강했지만 구현이 복잡하다는 단점이 존재한다 |
| 69 | + |
| 70 | + - 매 요청마다 복잡한 서명(Signature) 생성해서 요청에 포함했어야 함 |
| 71 | + - Request Token, Access Token을 사용하고 만료 기한이 없음 |
| 72 | + - request token: 사용자가 아직 로그인/권한 허용을 하지 않은 상태에서 발급, 인증 전 권한 요청을 위해 쓰임 |
| 73 | + - HTTPS 없이도 비교적 안전하게 동작 가능 |
| 74 | + - 구현 난이도가 높고 개발 생산성이 떨어짐 |
| 75 | + |
| 76 | + ### OAuth 2.0 |
| 77 | + |
| 78 | + OAuth 1.0을 단순화한 버전 |
| 79 | + |
| 80 | + - 서명을 없애고 HTTPS 사용을 강제로 해서 통신 암호화를 맡김 |
| 81 | + - 개발자는 단순히 발급 받은 토큰을 HTTP 헤더(Bearer Token)에 담아서 보내기만 하면 됨 |
| 82 | + - Access Token과 Refresh Token의 개념이 공식적으로 도입되어 만료 기한을 가짐 |
| 83 | + - 다양한 인증 방식을 가짐 |
| 84 | + - 구조가 단순해져 구현과 유지보수가 쉬움 |
| 85 | + - 모바일 앱, SPA, 서버 애플리케이션 등 다양한 환경 지원 |
| 86 | + |
| 87 | + **OAuth 1.0** |
| 88 | + |
| 89 | + → 요청 자체를 Signature로 보호 |
| 90 | + |
| 91 | + **OAuth 2.0** |
| 92 | + |
| 93 | + → HTTPS 기반 Token 인증 방식 사용 |
0 commit comments