오배이안 🪙
토큰
세션 방식은 유저의 상태를 서버에서 관리하게 된다. 서버에서 사용자의 상태를 관리하기 때문에
사용자가 급증하게 되면 서버의 부하가 심해지고, 메모리의 용량또한 많이 사용하게 되어 이를 보완하고자 토큰기반 인증방식이 등장하게 되었다.
토큰 기반 인증 방식은 클라이언트에 사용자의 인증 상태를 저장하기 때문에, 세션 인증 방식 보다 서버의 부담이 크게 줄어들게 된다.
옛날의 버스 토큰을 사용한거와 같이 웹 보안에서의 토큰은 어떠한 사이트의 인증과 권한 정보를 담고 있는 문자열로 이를 클라이언트가 저장하고 있다가 해당 웹 사이트에 접근할 시 토큰을 보여주면 인증된 사용자라고 인식하게된다. 즉, 사용자의 접근 권한을 부여할 수 있게 되는 것이다 토큰을 이용해서!
토큰의 인증 방식
사용자가 인증 정보를 담아 서버에 로그인 요청을 보냅니다.
서버는 데이터베이스에 저장된 사용자의 인증 정보를 확인합니다.
인증에 성공했다면 해당 사용자의 인증 및 권한 정보를 서버의 비밀 키와 함께 토큰으로 암호화합니다.
생성된 토큰을 클라이언트로 전달합니다.
HTTP 상에서 인증 토큰을 보내기 위해 사용하는 헤더인 Authorization 헤더를 사용하거나, 쿠키로 전달하는 등의 방법을 사용합니다.
- 클라이언트는 전달받은 토큰을 저장합니다.
저장하는 위치는 Local Storage, Session Storage, Cookie 등 다양합니다.
- 클라이언트가 서버로 리소스를 요청할 때 토큰을 함께 전달합니다.
토큰을 보낼 때에도 Authorization 헤더를 사용하거나 쿠키로 전달할 수 있습니다.
- 서버는 전달받은 토큰을 서버의 비밀 키를 통해 검증합니다. 이를 통해 토큰이 위조되었는지 혹은 토큰의 유효 기간이 지나지 않았는지 등을 확인할 수 있습니다.
- 토큰이 유효하다면 클라이언트의 요청에 대한 응답 데이터를 전송합니다.
토큰 사용 방식의 장점
토큰을 사용하게 되면 가지는 장점으로는
-
무상태성: 서버가 유저의 상태 유지를 하지 않아도 된다..! -
확장성: 세션의 경우 클라이언트에서 요청이 들어오면 유저의 정보를 저장한 서버와 연결이 되어야 사용자 접근 권한이 부여할 수 있게 되지만, 토큰의 경우 공통된 세션 데이터 베이스를 가질 필요가 없다..! -
어디서나 토큰 생성 가능: 토큰 생성과 검증이 하나의 서버에서 이루어지지 않아도 상관 없기 때문에 토큰 생성만 담당하는 서버를 구축할 수 있다..! -
권한 부여에 용이
JWT (JSON Web Token)
JWT는 토큰 인증 방식 중 하나로 JSON 객체에 정보를 담고 이를 토큰으로 암호화해 전송하는 기술이다.
JWT의 구성
사진과 같이 Header , payload, Signature 으로 구성된다.
-
Header: 토큰 자체를 설명하는 데이터가 담긴다. -
Payload: 전달하는 내용을 담는 곳이다 (body) -
Signature: 헤더에서 지정한 알고리즘으로 헤더와 페이로드를 묶어 해싱하는데 Salt솔트를 추가해 알아볼 수 없게 암호화 하는 작업을 담당한다.
(해커의 침입을 방지..!)
해싱이란?(Hashing)
해싱은 정보를 암호화(정보를 암호화 시키는 것)만 하는 것으로 복호화(암호화 시킨 정보를 알아볼 수 있게 푸는 작업)는 하지 않는다.
해싱은 암호화를 하는 방식으로 암호화만 가능하고 복호화는 하지 못한다.
- 암호화 : 정보를 암호로 변경시켜 알아보지 못하게 만드는 것
- 복호화 : 암호화된 정보를 알아 볼 수 있게 만드는 것
해싱은 해시 함수를 사용하여 암호화를 진행하는데
- 항상 같은 문자열을 리턴하고
- 같은 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과 값이 나온다는 특징이 있다.
해시 함수 중 하나인 SHA 1 으로 해싱 해보기 들어가서 실제로 해 볼 수 도 있다.
해싱의 특징으로는 같은 문자열을 넣으면 항상 같은 결과 값을 가진다고 했다. 그럼 이 결과 값을 리스트로 만들어 놓고 해싱 이전의 값을 유추할 수도 있지 않을까?
그렇다..! 이 해싱한 결과 값들을 모와서 해싱 이전의 값을 유추할 수 있는 리스트인 레인보우 테이블이 존재한다..! 만약 이 레인보우 테이블이 유출된다면,, 해싱한 의미가 없어지는 것이다..!
이때 사용하라고 만든 것이 솔트(Salt) 이다.
솔트는 해싱을할려는 데이터에다가 임의의 값을 더해 레인보우 테이블로 알아 볼 수 없도록 데이터를 암호화 시키는 것을 말한다.
데이터+ Salt = 해싱한 값 (레인보우 테이블로 알아 볼 수 없음) Salt는 랜덤 값이라 계속 변경 됨
왜 해싱을 사용하는 걸까?
해싱은 암호화만 가능하다고 했다 즉, 복호화를 하지 못해 해당 정보가 어떤 정보인지 알아 볼 수 없다는 뜻이다.
예를들어 사이트 관리자의 경우에는 해당 사이트를 이용하는 사용자의 비밀번호와 같이 민감한 정보를 알고있을 필요가 없다. 알고 있다면 악용할 소지가 있기 때문에 해당 사이트의 데이터 베이스에 사용자의 비밀번호와 같은 민감한 정보들은 해싱을 통해 암호화 시켜 저장하게 된다. 정확한 비밀번호를 몰라도 해싱한 값의 일치 여부로 회원인증이 된 유저인지 아닌지를 판별 할 수 있다..!
이처럼 해싱은 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해서 사용되는 단방향 암호화 방식이다!
토큰 인증의 한계
다시 토큰으로 돌아와서 토큰 인증이 가지는 한계로는
-
무상태성 : 서버에서 사용자의 상태를 유지 하지 않기 때문에 클라이언트가 가지고 있는 토큰이 해커에의해 탈취가 되면 해당 토큰을 강제로 만료 시킬 수 없다..! (가장 큰 단점이 아닐까 싶다)
-
유효 기간 : 토큰이 탈취되는 상황을 대비해 토큰의 유효기간을 짧게 설정하는 것도 방법이다.
하지만 유효 기간이 짧을수록 사용자의 경험 (UX) 가 상당히 안좋아질것이다.. (계속 다시 로그인 해야하니까..!) -
토큰의 크기 : 토큰에는 여러정보를 담을 수 있다 (페이로드에) 그렇기 때문에 담긴 정보의 양에 따라서 네트워크 비용이 천차만별일 것이다.!
유효기간의 문제 해결 방안
토큰 인증 방식의 문제점인 유효기간을 두고 다양한 방법들이 고안되었지만 가장 많이 사용되는 방법이
엑세스토큰(Access Token) & 리프레시 토큰(Refresh Token) 을 사용하는 것이다.
-
엑세스 토큰(Access Token) : 서버에 접근하기 위한 토큰으로 일반 토큰의 역할을 한다. 단 유효기간이 짧다.
-
리프레시 토큰 (Refresh Token) : 엑세스토큰이 만료되면 리프레시토큰의 유무로 엑세스토큰을 재발급받아서 로그인을 유지할 수 있게 도와주는 역할이다. 따라서 엑세스 토큰의 유효기간보다 더 긴 유효기간을 가져야 한다.!
OAuth
OAuth 란 인증을 중개해주는 메커니즘이다.
전통적으로는 하나의 웹 사이트는 해당 사이트에서 회원가입을 하고 그 정보를 해당 웹 사이트에서 사용자 인증을 토큰 방식이던지 세션 방식이라던지 어떠한 방식을 통해서 관리하게 되는데 최근? 근래? 들어서는 OAuth 를 활용하여 사용자인증을 중개해주는 메커니즘으로 웹 사이트 로그인을 구현하는 곳들이 대부분이다..!
예시로 프로그래머스 로그인 페이지를 보면 구글,카카오,깃허브,페이스북을 통해서 로그인을 할 수 있도록 만들어놨다. 이를 가능하게 하는 것이 OAuth 메커니즘이다..!
OAuth 의 주체
-
Resource Owner사용자 : OAuth 인증을 통해 해당 웹 사이트를 로그인 하고 싶어 하는 사용자를 말한다. -
Resource Server리소스 서버 : 이미 사용 중인 서비스의 사용자의 정보를 저장하고 있는 서버 (위의 사진에선 구글,카카오,깃허브,페이스북에서 사용자의 정보를 저장하고 있는 서버를 말한다.) -
Authorization Server인증담당 서버 : 이미 사용 중인 서비스의 사용자의 인증을 담당하고 있는 서버
OAuth 의 인증 방식
Grant Type - 엑세스 토큰을 받아오는 방식을 말한다.
1. Implicit Grant Type
실무에선 거의 사용되지 않는다고 들었다..! (보안때문에?)
기존에 이미 사용 중인 서비스에 로그인만 되어 있다면 새로운 웹 사이트에 바로 엑세스 토큰을 발급해주기 때문이다!
2. Authorization Code Grant Type
1번 방식에서 인증 단계를 추가한 방식이다. 인증 단계를 추가했기 때문에 비교적 더 안전하다!
하지만 사용하다가 엑세스 토큰이 만료될 경우 다시 이 과정을 거쳐야 하기 때문에
리프레시 토큰을 같이 발급해주는 방법도 있다.
3. Refresh Token Grant Type
사진 출처 : 코드스테이츠~!
