Login Process

우리는 웹사이트를 이용할 때 로그인을 하고 이용을 한다. 그러다 문득 로그인이 어떻게 이루어지는지 궁금해지기 시작했다. 그래서 로그인의 과정을 적어보려고 한다.

로그인에는 여러가지 방식이 있다.

세션,쿠키 방식

1. 로그인 페이지에서 아이디와 비밀번호를 적은 뒤 서버로 보낸다.
2. 서버는 확인을 한 뒤 회원가입을 한 사람이면 세션ID를 주고, 세션 ID를 변수,DB에 저장한다.(세션 저장소라고 부른다.)
3. 세션ID를 받은 사용자는 쿠키에 저장하고 로그인이 필요한 서비스가 있으면 쿠키를 header에 담아서 보낸다.
4. 서버는 쿠키를 받아서 세션 저장소 정보와 대조한다.

세션,쿠키 방식의 장단점

• 장점 : 쿠키를 가지고 인증을 거치므로 http 요청이 탈취당하여도 안에 유의미한 값이 없기때문에 괜찮다.(대신 https 요청을 사용해서 안의 정보를 어렵게 만들 필요가 있다.)
• 단점 : 서버에서 세션 저장소라고 부르는 곳에 저장을 하기 때문에 서버에 부하가 생길 수 있으며 확장성이 낮아진다.

토큰 인증 방식(JWT) - accessToken

1. 로그인 페이지에서 아이디와 비밀번호를 적은 뒤 서버로 보낸다.
2. 서버에서 아이디와 비밀번호를 확인한 후 accessToken을 보내준다.
3. 사용자는 이 accessToken을 받아 저장해두고, 로그인이 필요한 페이지에 접속할 때 accessToken을 header에 포함시켜 보낸다.
4. accessToken이 이상이 없는지 검증하고 응답을 보낸다.

accessToken만 사용할 경우의 단점

• 해킹당했을 경우 보안에 취약하다.
• 유효기간을 짧게하기 때문에 로그인을 자주 해야한다.

토큰 인증 방식(JWT) - accessToken + refreshToken

1. 로그인 페이지에서 아이디와 비밀번호를 적은 뒤 서버로 보낸다.
2. 서버에서 아이디와 비밀번호를 확인한 후 accessToken,refreshToken을 만든 후 보내준다.(refreshToken의 유효기간을 accessToken보다 길게한다.)
3. 사용자는 refreshToken을 쿠키에 저장하고 로그인이 필요한 페이지는 accessToken을 header에 담아 보낸다.
4. 서버는 accessToken을 검증한다.
5. accessToken의 유효기간이 끝났다면, 서버는 토큰이 유효하지 않다고 응답을 보낸다.
6. 사용자는 refreshToken과 accessToken을 보낸다.
7. 서버는 refreshToken을 검증한뒤 맞다면 새로운 accessToken을 보낸다.

accessToken+refreshToken의 장단점

• 장점 : accessToken의 유효기간이 짧기 때문에, accessToken만 사용하던 방식보다 안전하다.
• 단점 : accessToken이 만료될 때마다 새롭게 발급해야해서 서버의 자원 낭비가 생긴다.

참고한 사이트 : https://velog.io/@devstone/%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%EC%99%80-%EC%84%9C%EB%B2%84-%EC%96%91-%EC%9E%85%EC%9E%A5%EC%97%90%EC%84%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EA%B3%BC%EC%A0%95-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-feat.-session-JWT%EC%86%8C%EC%85%9C%EB%A1%9C%EA%B7%B8%EC%9D%B8
https://velog.io/@gusdnr814/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D-4%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95