로그인 기능 구현 - 로그인 인증방법 정리

로그인 인증방법 정리

---

뮤지컬을 추천해주는 프로젝트를 진행중이다.

궁극적으로는 웹사이트에서 사용자별 추천시스템과, 커뮤니티 기능을 구현할 것이기에, 로그인 기능이 필요하다.

로그인 기능 구현에 앞서서 인증방법에 대해서 조사하면서 정리해봤다.

 

 

로그인 인증 방식

---

- Cookie & Session

- JWT(Access Token / Refresh Token)

- OAuth 2.0

- SNS

인증을 왜 해야 하나요?

---

인증은 프론트쪽에서 생각했을때, 비회원과 회원을 구분하는 시작부분이라 볼 수 있다. 서버사이드 쪽에서 본다면 사용자를 확인하는 작업이기도 하다.

현재 모바일/웹에서 가장 많이 쓰이는 통신 방식은 HTTP 통신이다.

HTTP는 응답하고나서 연결이 끊기고, 연결이 끊긴 이후에는 연결정보가 사라진다.  따라서 HTTP 요청을 두번 보낸다면,

1번과 2번의 요청은 전혀 관계가 없는 서로 다른 요청이 된다.

 

서버에 HTTP 요청을 보낸다는 것은 HTTP 메시지를 보내는 것이다.

HTTP 메시지의 구조는 헤더와 바디로 되어있고, 이 구분은 공백으로 되어있다. 

HTTP 메시지 구조 (https://developer.mozilla.org/ko/docs/Web/HTTP/Messages)

그림을 참고하면, 헤더에는 기본적으로 요청에 대한 정보가 들어가있고, 바디에는 서버로 보내야할 데이터가 들어가있다.

보통 모바일/ 서비스는 헤더에 인증 수단을 넣어 요청을 보낸다. 인증방법들은 다음과 같다.

 

헤더에 계정정보 넣는방법 (서비스에서 사용X)

---

보안이 가장 취약한 방법이며, HTTP 요청 메시지에 비밀번호를 넣는 방식이다.

이렇게 할 경우 데이터 요청시마다 사용자의 개인정보인 비밀번호 같은 민감한 정보들을 보내기때문에 보안에 좋지않다.

(따로 암호화를 거치지않기때문에) 따라서 해커가 이 정보들을 가로챈다면 위험하기때문에 실제 서비스에서는 절대 쓰면 안된다. 

(장점) 개발단계에서 빠르게 테스트가능

(단점) 보안 매우 취약, 요청시마다 인증을 해야하므로 비효율적

 

 

 

 

1. Cookie & Session

---

쿠키(Cookie) 세션(Session) 을 왜 쓰나요? (쿠키와 세션에 관한글 더보기)

1번 방식(HTTP 통신)의 요청에 대한 응답이후 종료되는 stateless 방식의 해결을 위한 방법으로 쿠키 또는 세션을 사용한다.

 

쿠키와 세션의 장단점

항목	쿠키	세션
보안	취약(로컬에서 전송시 스니핑우려)	좀 더 우수(서버에 저장)
요청속도	빠름	비교적 느림(서버거침)
라이프사이클	만료시간	브라우저 종료
메모리	로컬 메모리	서버 메모리(동접자 ↑ 과부하)

쿠키는 로컬에 저장되기에 서버에 요청하는 과정에서 해커에게 스니핑을 당할 위험이있다.

세션ID도 관리자의 세션ID를 탈취해서, 쿠키를 관리자의 세션ID로 변경해서 관리자 권한을 이용해 해킹하는 방식이 있는다.

이를 해결하기위해서 로그인 ID를 저장하고, 페이지 이동 or 요청시에 현재 IP와 세션의 브라우저IP와 유저 ID가 같은지를 체크하는 방식이 있다.

 

 

 

2. 토큰 인증 방식 JWT(Access Token / Refresh Token) 

---

JWT란?

2번의 세션인증 방식은 사용자의 수 만큼 메모리가 들어가기때문에, 이런 문제들을 해결하기 위해서 토큰 인증방식을 사용한다.

JWT은 JSON Web Token으로 사용자를 인증 및 식별하기 위한 정보들을 저장한 토큰이다.

JSON Data를 URL문자(Base 64 URL-safe Encode)로 인코딩해서 직렬화한 것이다.

전자서명도 가능해서 위/변조를 체크할 수 있고 쿠키를 통해서 클라이언트에 저장된다.

HTTP요청시 헤더에 토큰을 첨부해서 사용한다.

'.'을 기준으로 Header, Payload, Signature가 나누어지며 구조는 다음과 같다.

JWT 구조 출처 : https://velopert.com/2389#google_vignette

JWT 자세한 설명 출처 : https://velog.io/@dee0518/

Header

토큰의 타입과 암호화알고리즘을 나타낸다.

alg	해시 암호화 알고리즘 종류
typ	토큰 타입

Payload

토큰에 담을 클레임 정보. name/value쌍으로 이루어져있으며, 여러개의 클레임이 담길 수 도있다.

sub(Subject)	토큰의 제목이자 식별값
iss(Issuer)	발급자
aud(Audience)	토큰 대상
exp(Expiration)	토큰의 만료시간
nbf(Not Before)	토큰 활성날짜(이전에는 활성X보장)
iat(Issued At)	토큰 발급 시간
ti(JWT ID)	JWT 토큰 식별(iss 여러명일때 구분)

 

Signature

시크릿키를 포함 암호화.

Signature는 사용자별로 사용자 정보를 기반으로 암호화해서, 해커가 Payload값을 변경해서 해킹을 시도해도 유효하지 않은 토큰으로 인식한다.

인증방식

JWT는 Access Token만으로도 구현이 가능하나, 한번 발급되면 유효기간 만료시까지 삭제가 불가능해, 해킹당하면 위험하다. (유효기간을 짧게하면 자주 인증해야하니 불편하다)

그래서 Refresh Token을 함께 발급하여 이를 대처한다.(Access Token보다 유효기간이 길고, Access 만료시 새로 발급해주는 키 토큰)

Refresh Token도 탈취 위험이있으나, Access Token이 만료되었을때만 네트워크에서 서버로 보내기때문에 탈취 위험이 줄어든다.

 

인증순서

출처 : https://velog.io/@dee0518

1) 사용자가 로그인하면 서버는 회원확인하고 JWT을 생성해서 응답한다.(Access + Refresh)

2) 사용자는 요청시 마다 Access Token을 사용해 요청한다.

3) 서버에서 Access Token을 검증해 응답한다.

* Access Token 만료 시

1) 사용자가 Access Token과 함께 요청했다.

2) 서버에서 토큰이 만료된것을 확인해서 만료되었다는 것을 응답.

3) 사용자는 Access Token + Refresh Token 을 함께 보내서 요

4) 서버에서 Refresh Token 확인 후 Access Token 발급해 응답

5) 사용자는 새로 발급된 Access Token을 사용해서 요청

 

 

 

3. OAuth(Open Authorization)

---

OAuth란?

 

 

 

 

 

< 참고자료 감사합니다. >

Hyuntae :  https://medium.com/@hwanght1/what-is-jwt-89889759ae37

dee0518 : https://velog.io/@dee0518/ (4가지 로그인인증방식) 

그랩의 블로그 : https://tansfil.tistory.com/58?category=475681 

RyanGomdoriPooh : https://interconnection.tistory.com/74 (쿠키와 세션차이)