로그인, 그 참을 수 있는 무거움

일단 로그인의 구현 방식은 대략 3가지로 보면 된다.

• Session & Cookies
• Access Token ( + Refresh Token 의 조합방식 )
• OAuth2.0

Session & Cookies

이런 과정을 거친다

1. 사용자가 로그인을 요청을 보낸다
2. 서버에서는 계정 정보를 읽어 사용자를 확인한다
3. 사용자에게 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 Session ID를 생성한다
4. 서버는 HTTP 응답 헤더에 발급된 Session ID를 포함시켜 대답한다

---

• 사용자는 다음부터 요청마다 HTTP 요청 헤더에 Session ID가 담킨 쿠키를 실어 보낸다
• 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 누구인지 확인한다
• 인증이 완료되고 서버는 사용자가 요청한 것에 응답한다

역사와 전통의 쿠키쿠키. 사용자의 정보는 세션 저장소에 저장되고, 쿠키는 그 저장소를 통과할 수 있는 출입증이다.

따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되어도 괜찮다. 어차피 쿠키 자체에는 유의미한 값을 갖고있지 않기 때문.

각각의 사용자는 고유의 Session ID를 발급 받기 때문에 일일이 회원 정보를 확인할 필요가 없어 서버 자원에 접근하기 편하다.

그러나

• 쿠키에 사용자 정보를 담아 인증을 거치는 것 보다 안전하지만, 타인이 쿠키를 탈취한 후 그 쿠키를 이용해 HTTP 요청을 보내면 서버는 사용자로 오인해 정보를 전달하게 된다
• 이를 세션 하이재킹 공격이라고 합니다. 해결책으로는 HTTPS 프로토콜 사용과 세션에 만료 시간을 넣어주는 것
• 서버에서 세션 저장소를 사용하기 때문에 추가적인 저장공간이 있어야 한다. 큰 문제는 아님

Access Token

JWT에 대해서는 이미 한번 다룬적이 있다.

중간자 공격으로 부터의 탈출 : JWT (tistory.com)

중간자 공격으로 부터의 탈출 : JWT

토큰을 이용한 로그인 과정

1. 사용자가 로그인을 한다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여하고 Payload에 정보를 넣는다.
3. JWT 토큰의 유효기간을 설정
4. SECRET KEY로 암호화된 Token을 HTTP 응답 헤더에 실어 보낸다
5. 사용자는 Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 HTTP 요청 헤더에 첨부한다
6. 서버에서는 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효 기간을 확인
7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다

---

• 간편하다! 쉽다! 마참내!
• JWT는 발급 후 검증만 거치면 되기 때문에 추가 저장소가 필요없다
• 확장성이 뛰어나다. SSO를 막 적용할 수 있다

문제라고 한다면,

• JWT는 한 번 발급되면 유효기간이 완료될 때까지는 계속 사용이 가능하다는 점
• 원격으로 중간에 삭제가 불가능하므로, 정보가 털린다면 대처할 방법이 없다
• 해결책으로는 Refresh Token을 추가적으로 발급
• Payload 정보가 디코딩하면 누구나 접근할 수 있기에 중요한 정보들을 보관할 수 없다
• JWT의 길이가 길기 때문에, 인증 요청이 많아지면 서버의 자원낭비가 발생

Refresh Token

결국 그 해결책이라는 것도 이미 있다. 추가적으로 Refresh 토큰을 발급하면 된다. 아니면 유효기간을 짧게 가져가던가. 인증 갱신이라고 보면 된다. 좀 더 긴 기간의 JWT를 추가로 발급해서 서로가 서로를 보완하게 한다. 벌써 복잡시러울 것이 훤하다.

OAuth 2.0

2012년에 발표된 OAuth 2.0은 외부서비스의 인증 및 권한부여를 관리하는 범용적인 프로토콜이다. 약속이라는 뜻이다. 일단 신식이고, 모바일같은 환경에도 대응하면서, 반드시 HTTPS를 사용하는 등 가장 최신 표준안에 가까운 느낌이다.

일단 딱 봐도 다른점은 검증하는 곳이 제3서버라는 것이다

• Resource Owner : 일반 사용자
• Client : 우리가 만든 웹 어플리케이션
• Authorization Server : 권한 관리 및 Access Token, Refresh Token을 발급해주는 서버
• Resource Server : OAuth 2.0을 관리하는 서버의 자원을 관리하는 곳

출처:

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

로그인 인증 4가지 방법

JWT 실 구현시 참고

https://velog.io/@_woogie/JWT-%EB%A1%9C%EA%B7%B8%EC%9D%B8%EB%B0%A9%EC%8B%9D-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0-feat.-session%EC%97%90%EC%84%9C-jwt%EB%A1%9C

JWT 로그인방식 구현하기 (feat. session에서 jwt로)