✅ 왜 알아야 하는가?
Auth(인증)을 통해서 서비스는 유저를 검증할 수 있음. 하지만 이를 위해서 쿠키와 토큰, 세션과 JWT를 알고 적재적소로 적용해야하기 때문에 알아야 해.
✅ 쿠키 vs 토큰
☑️ 쿠키
Cookie를 이용해서 서버는 이용자의 브라우저에 데이터를 넣을 수 있어. 왜냐하면 이용자의 관한 것들을 기억하기 위해서 흔적을 남겨두는 행위이기 때문이야. 정보를 담는 그릇 같은 존재!
-
Cookie는 도메인에 따라 제한이 있어.ex) 유튜브가 준 쿠키는 유튜브에만 보내지게 됨
쿠키는 유효기간이 있음(서버에 따라 다름)공간 제약이 있음 -
Cookie는 인증 뿐만 아니라, 여러 가지 정보를 저장할 수 있음 ( 하나의 매개체 )
ex) 웹 페이지 번역을 하게 되면, 서버로부터 쿠키가 브라우저로 전달되고 그 쿠키에 해당 번역 정보가 저장이 됨. 그리고 웹페이지에 방문할 때 마다, 그 쿠키의 내용을 서버에 전달하여 지속적인 번역 서비스를 이용자가 제공받게 됨 -
요청(request)와 응답(response)을 통한
Cookie의 역할은?
사이트 방문→브라우저는 서버에 request→서버는 response(모든 데이터 + 이용자가 찾던 페이지 정보가 있음)→그리고 쿠키마저도 response에 담겨서 브라우저에 저장→그리고 이용자가 웹사이트에 방문할 때 마다 해당 쿠키도 요청과 함께 보내게 됨 -
안드로이드앱과 IOS에서는 지원이 되지 않음. 그래서 다음과 같은
Token을 사용함
☑️ 토큰
서버에 Cookie 대신 Token을 보냄(안드로이드 및 IOS에서)
-
Token은 그냥 이상하게 생긴 string -
Cookie처럼Token도Session DB로 가서 해당Token과 일치하는 유저를 찾아서 확인
✅ 세션
☑️ 세션
서버로 가는 모든 요청이 이전 요청과 독립적으로 다뤄지는 것을 stateless 라고 하는데, 이러한 요청이 끝나면, 서버는 이용자가 누구인지 잊어버림. 그래서 필요한게 Session.
-
로그인을 하는 절차는 다음과 같은데,
유저명 그리고 비밀번호를 서버에 보냄→비번이 맞으면, 서버는 Session DB에 유저를 생성
→해당 Session에는 별도의 ID가 있음→해당 Session ID는 쿠키를 통해 브라우저로 돌아오고 저장됨→같은 웹사이트의 다른 페이지로 가면 해당 Session ID 쿠키를 서버로 보냄→
해당 Session ID를 서버가 Session DB로 가져가서 확인→해당 ID가 해당 유저의 것임을 확인→인증완료→같은 웹사이트 다른 페이지로 가도 해당 위의 프로세스가 반복되면서 지속적인 로그인이 가능해짐 -
현재 로그인한 유저들의 모든
Session ID를 DB에 저장해야한다는 것을 유념해야 함 -
그래서 유저의 수가 늘어날 수록 DB가
Scale Out해야함 ( 비용 증가 ) -
Session을 사용하면 서버는 로그인 된 유저의 모든 정보를 저장하여, 해당 정보를 통해서 새로운 기능을 추가할 수 있음ex) 특정 유저 강제 로그아웃(세션 삭제)인스타그램의 원하지 않는 디바이스에서 강제 로그아웃넷플릭스 계정 공유 숫자 제한 -
주로
Session DB는redis
☑️ JWT
-
JWT는Token형식. 보통Session ID 보다 훨씬 길다. (제약이 없기 때문에 한계가 없음) -
Session DB가 필요없음.암호화도 되어 있지 않음 -
서버는 유저인증 한다고 DB로 가서 확인하는 등의 작업을 생략해도 됨.
그대신,싸인 알고리즘을 통해서싸인된 로그인 정보를 string 형태로 유저에게 전달.
→동일하게 로그인 할때, 토큰이나 싸인된 정보를 서버로 보내면→토큰의 조작여부과 싸인된 정보가 맞는지 서버는 확인→인증완료→같은 웹사이트 다른 페이지로 가도 해당 위의 프로세스가 반복되면서 지속적인 로그인이 가능해짐 -
이렇게 서버는 해당 토큰 및 정보가 유효한지만 검증하면 됨!
-
추가적인 기능을 실현 불가능
Session과 달리! -
ex) 코로나 QR 체크인
구조
JWT는 Header, Payload, Signature 로 구성.
Header
- JWT 에서 사용할 타입과 해시 알고리즘의 종류
- typ: 토큰의 타입을 지정합니다. 바로 JWT를 말하는 것입니다.
- alg: Signature 해싱 알고리즘을 지정합니다. 해싱 알고리즘으로는 보통 HMAC-SHA256 혹은 RSA 가 사용되며, 이 알고리즘은 토큰을 검증 할 때 사용되는 signature 부분에서 사용됩니다.
{
"typ": "JWT",
"alg": "HS256"
}Payload
-
서버에서 첨부한 사용자 권한 정보와 데이터
-
Payload 부분에는 토큰에 담을 정보가 들어있습니다. 여기에 담는 정보의 한 ‘조각’ 을 클레임(Claim) 이라고 부르고, 이는 Json(Key/Value) 형태의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임들을 넣을 수 있습니다.
- 클레임 의 종류는 다음과 같이 크게 세 분류로 나뉘어져있습니다:
- 등록된 (registered) 클레임
공개 (public) 클레임
비공개 (private) 클레임
- 등록된 (registered) 클레임
-
등록된 클레임(Registered Claim)
- 등록된 클레임들은 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기위하여 이름이 이미 정해진 클레임들입니다. 등록된 클레임의 사용은 모두 선택적 (optional)이며, 이에 포함된 클레임 이름들은 다음과 같습니다.
- iss
토큰 발급자 (issuer) - sub
토큰 제목 (subject) - aud
토큰 대상자 (audience) - exp
토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야합니다. - nbf
Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념입니다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않습니다. - iat
토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있습니다. - jti
JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용됩니다. 일회용 토큰에 사용하면 유용합니다.
-
공개 클레임(Public Claim)
- 공개 클레임들은 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 합니다. 충돌을 방지하기 위해서는, 클레임 이름을 URI 형식으로 짓습니다.
{
"https://dnjscksdn98.com/jwt_claims/is_admin": true
}- 비공개 클레임(Private Claim)
- 등록된 클레임도아니고, 공개된 클레임들도 아닙니다. 양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임 이름들입니다. 공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할때에 유의해야합니다.
{
"username": "velopert"
}- Payload 예시
{
"iss": "dnjscksdn98.com",
"exp": "1485270000000",
"https://dnjscksdn98.com/jwt_claims/is_admin": true,
"userId": "dnjscksdn98",
"username": "alex"
}위 예시 Payload는 2개의 등록된 클레임, 1개의 공개 클레임, 2개의 비공개 클레임으로 이뤄져있습니다.
Signature
-
서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다. 서명은 위에서 만든 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성합니다.
-
생성된 토큰은 HTTP 통신을 할 때 Authorization이라는 key의 value로 사용됩니다. 일반적으로 value에는 Bearer가 앞에 붙여집니다.
{
"Authorization": "Bearer {생성된 토큰 값}",
}일단 알겠는데... 어떻게 써먹는거야?? ㅠ
