서버 인증방식

웹 싸이트에서 유저의 인증을 확인하는 방식에는 여러 방식이 존재한다.

 

각 방식에 대해서 간단하게 알아보자.

 

1. 단순하게 Http Header에 특정 정보를 전달하는 방식.

- 해당 방식은 Client와 Server가 통신할 때마다 Header 에 Id, pw 등의 정보를 포함 시킨 후 

통신하는 방식이다. 매 통신마다 해당 정보를 검증하며 위조여부 등을 판단한다.

 

-> 단점 :

. 해커가 해당 패킷을 탈취 시 중요 정보가 유출된다.

. 매번 인증정보를 확인해야 하며 이는 비효율적이다.

-> 장점 : 

. 구현이 쉽다.

 

2. 서버가 유저 인증 시 특정 세션정보를 활용하는 방법.

 - 유저의 로그인 절차 중 해당 정보가 인증된다면 이 유저에 대한 세션ID를 부여한다.

그 후 세션 ID를 Header에 포함시켜 보내면, client는 해당 session id 를 쿠키에 저장한 후 

서버와 통신할 때 인증정보가 필요한 경우 header에 포함시킨다.

 

-> 단점 : 

. 이 역시 해커가 탈취 시 중요 정보의 유출 위험이 존재한다.

 -> 세션 별 life time 을 설정해서 유효시간을 지정함으로서 탈취된 경우 무효화 될 수 있게 한다.

 -> HTTPS를 적용하여 탈취 후 에도 header를 파악하기 어렵게 한다.

. 세션을 저장할 추가적인 비용(DB, memory 등)가 발생한다.

-> 장점 : 

. 패킷 탈취 시 해당 session ID로만 구성되어 있으므로 유의미한 정보는 유출되지 않는다.

 

3. Token 기반 인증방식을 적용한다.(보통은 JSON Web token 사용)

 - token 정보를 header에 포함시켜 전달하는 방식이다. jwt의 경우 지정된 암호화 방식으로 tokenize를 진행할 수 있고 이에 대한 SECRET KEY 로 복호화 후 위변조 여부를 판단할 수 있다.

jwt의 경우 Header, payload, verify signature 로 구성되며 header, payload는 누구나 복호화 할 수 있고 verify signature의 경우 SECRET KEY를 알지못하면 복호화 하지 못한다. 따라서 payload에는 중요정보를 포함하면 안된다.

 

-> 단점 : 

 . 이 방식 역시 해커가 탈취가능하다.

 -> 이 역시, access token에 expire time을 적용하면 피해를 다소 방지할 수 있다.

 . payload는 복호화가 가능하기 때문에 넣을 수 있는 data는 한정적이다.

 . 서버에서 복호화하는 비용이 발생한다.

-> 장점 : 

 . session 인증 방식과 크게본다면 동일하지만 볃도의 비용이 발생하진 않는다.(DB 불필요)

 . 탈취 당한다고 해도 token 위조가 무의미해진다.