로그인 상태에는 실제로 소위 '상태'가 없습니다. http 자체는 상태 비저장(stateless)이기 때문입니다. 따라서 클라이언트가 서버에 대한 요청을 시작할 때마다 서버는 인증을 받아야 합니다.
처음 : 사용자가 사용자 이름과 비밀번호 인증을 제공하고 서버는 "사용자 이름 + 비밀번호"를 통해 사용자를 인증합니다. 통과 후 서버는 인증 ID를 생성합니다. 서버는 이 인증 ID를 저장하고 클라이언트에 인증 ID로 응답합니다. 클라이언트도 이 인증 ID를 저장합니다.
2~n번째: 클라이언트는 저장된 인증 식별자를 사용하여 사용자를 대신하여 서버에 요청을 시작하고, 서버는 "인증 식별자"를 통해 사용자를 인증합니다.
인증 ID가 클라이언트의 쿠키 또는 로컬 저장소에 저장되는지 여부와 세션 메커니즘을 사용할지 아니면 사용자 정의 토큰 메커니즘을 사용할지 여부에 대해 설명합니다. 단지 구체적인 실행 계획일 뿐입니다.
브라우저를 사용하는 경우 일반적으로 쿠키+세션입니다. 앱과 같은 인터페이스인 경우 일반적으로 토큰 메커니즘이 사용자 정의됩니다.
왜 이러는 걸까요? 모든 요청에는 사용자가 사용자 이름과 비밀번호를 입력해야 하기 때문에 사용자는 미쳐버릴 것입니다.
그래서 클라이언트 에이전트(브라우저)가 사용자를 대체합니다. 인증 ID는 사용자 이름과 비밀번호를 대체합니다.
토큰을 저장하면 실제로 로그인 상태가 저장되지 않지만, 인터페이스 호출을 위한 토큰이 존재하고 만료되지 않은 한 여전히 로그인 상태인 것으로 간주됩니다.
서버 세션에 저장
토큰은 사용자 로그인 확인에 사용됩니다. 이는 단지 ID일 뿐이며 구체적인 내용은 서버측에 있습니다.
로그인 상태에는 실제로 소위 '상태'가 없습니다. http 자체는 상태 비저장(stateless)이기 때문입니다. 따라서 클라이언트가 서버에 대한 요청을 시작할 때마다 서버는 인증을 받아야 합니다.
처음 : 사용자가 사용자 이름과 비밀번호 인증을 제공하고 서버는 "사용자 이름 + 비밀번호"를 통해 사용자를 인증합니다. 통과 후 서버는 인증 ID를 생성합니다. 서버는 이 인증 ID를 저장하고 클라이언트에 인증 ID로 응답합니다. 클라이언트도 이 인증 ID를 저장합니다.
2~n번째: 클라이언트는 저장된 인증 식별자를 사용하여 사용자를 대신하여 서버에 요청을 시작하고, 서버는 "인증 식별자"를 통해 사용자를 인증합니다.
인증 ID가 클라이언트의 쿠키 또는 로컬 저장소에 저장되는지 여부와 세션 메커니즘을 사용할지 아니면 사용자 정의 토큰 메커니즘을 사용할지 여부에 대해 설명합니다. 단지 구체적인 실행 계획일 뿐입니다.
브라우저를 사용하는 경우 일반적으로 쿠키+세션입니다. 앱과 같은 인터페이스인 경우 일반적으로 토큰 메커니즘이 사용자 정의됩니다.
왜 이러는 걸까요? 모든 요청에는 사용자가 사용자 이름과 비밀번호를 입력해야 하기 때문에 사용자는 미쳐버릴 것입니다.
그래서 클라이언트 에이전트(브라우저)가 사용자를 대체합니다. 인증 ID는 사용자 이름과 비밀번호를 대체합니다.
다양한 기술 구현 솔루션은 안전과 효율성을 고려한 것일 뿐입니다
기본적으로 사용자가 매번 사용자 이름과 비밀번호를 입력하는 것과 다르지 않습니다