basic auth는 authorization 필드에 id와 비번 인코딩해서 보내고, 서버에서 디코딩
세션은 클라이언트에서는 세션 id를 저장 (쿠키나 로컬 스토리지에 저장). 단점은 서버가 여러개라면 어떤 서버와 통신했는지 기록을 해야한다는 단점. (sticky session) 이걸 위해 session 스토리지라는 것을 따로 두기 때문에 오버헤드가 있다. basic보다는 좀 더 안전한게, 서버는 클라이언트에게 세션id를 인코딩해서 줘서 클라이언트는 세션id만 스토리지에 갖고 있으면 되고, 탈취 당하는 상황이더라도 세션에 만료기간을 주거나 서버에서 해당 세션id 삭제할 수 있음.
앞서 방식들은 클라이언트, 서버, 스토리지 등이 상태를 갖고 있음. 무상태성이어야한다는 패러다임과 상충됨. 이걸 해결하기 위해, 즉 클라이언트 서버 스토리지가 상태를 갖는게 아니라, 요청과 응답과 같은 흐름 속에 사용자에 관한 상태를 담아내자. 그걸로만 사용자의 인증과 인가를 철리하자. 라는 취지로 나온게 토큰 방
토큰 방식은 JWT (액세스 토큰은 탈취 위험이 있어서, 만료 시간을 두고, 만료되면 갱신을 위해 리프레시토큰활용). JWT는 해독이 쉬운 편이므로 비밀번호와 같은 민감한 정보를 담지 않음.
얘네를 authorization 필드에서 구분하기 위해 Basic, Bearer와 같은 접미사를 붙이는듯??
만료된 토큰 지우기 : redis와 같은 휘발성 데이터베이스(expired 기간 설정) 등을 사용한다거나, 개발자가 주기적으로 직접 쿼리 한 번씩 수행해줘서 지워준다거나 등의 방법이 있음. 또는 스프링 스케줄러(배치)를 통해 주기적으로 작업시킬 수도 있음
사용자로부터 id, 비번을 인코딩한 authorization 헤더 필드를 서버가 받아서 스프링 시큐리티를 통해 우리 웹 플랫폼 자체적으로 사용할 토큰을 발급 및 클라이언트에게 제공. 클라이언트로부터 받은 토큰의 검증도 시큐리티가 수행. 유효하다면 디코딩해서 사용자 이름과 만료시기와 권한 정보를 알아냄. 서버가 여러개여도 각 서버의 시큐리티가 알아서 잘 해독해서 인증 인가 수행해주면
물론 얘도 문제가 있음. 토큰의 탈취 가능성이 있음. 이를 해소하기 위해 토큰의 만료 기간 정의 (보통 액세스 토큰 만료 주기는 길어도 1일 쯤, 짧으면 30? 그 정도로 짧은데, 그럼 그거 만료될 때마다 새로 로그인해서 토큰 새로 받아야하는데 귀찮으니까 이걸 해소하기 위해 리프레시 토큰 활용. 리프레시 토큰은 액세스 토큰 재발급 용도로만 쓰임. 서버 DB에는 인증 시 액세스 토큰과 리프레시 토큰을 둘 다 발급하는데, 서버는 리프레시 토큰만 저장해둠. 클라이언트는 액세스 토큰과 리프레시 토큰을 둘 다 저장하고 있는다.)
만약 클라이언트가 액세스 토큰을 같이 보내서 API 요청을 했는데 토큰 만료 응답을 받았으면 리프레시 토큰 보내서 액세스 토큰 재발급 요청. 리프레시 토큰도 만료됐으면 재로그인 요구 응답 등
