Cookie란?
로그인 했다는 정보를 유지 -> 로그인 되어있다는 사실을 저장해놓아야 한다는 의미.
내 컴퓨터를 클라이언트라고 한다면
웹사이트에서 클라이언트에 저장해 놓는 데이터를 "쿠키"라고 한다.
쿠키는 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 있다
일반적으로 쿠키에는 만료일이 있다.
예를 들어 브라우저를 닫는 경우 자동으로 삭제되는 쿠키도 있으며 (세션쿠키)
일부는 수동으로 삭제되기 전까지 남아있는 등 더 오랜기간 동안 컴퓨터에 저장되는 쿠키도 있다. (지속적 쿠키)
*주의 점
쿠키 값들은 자유롭게 편집이 가능하며 통신 상 유출되기 쉽다
-> 악의적으로 사용될 여지가 다분하다.
변경되어도 큰 상관 없는 값들은 써도 된다.
유저가 페이스북을 통해서 내 사이트에 왔는지, 네이버를 통해서 내 사이트에 왔는지 등
추적을 위한 값들도 쿠키에 담아서 사용하곤 하는데,
이런 값들은 변조해도 큰 문제가 없다.
그런데 변경해서 사용할 경우에 보안적인 이슈가 될 수 있다라는 것들은 절대 Cookie에 남기지 않아야 한다.
따라서 보안상 문제가 없지만 브라우저에 남기고 싶은 정보들을 Cookie 에 담는다.
현재 로그인 된 정보를 클라이언트의 쿠키가 아닌, 서버에 저장 -> 세선(Session) 이라는 이름으로.
추측하기 힘든 무작위의 해쉬값으로 생성한 뒤, 데이터베이스에 저장해 둔다.
이렇게 되면 다른 클라이언트에서 Session id를 추측할 수 없을 뿐더러
해당 Session id의 user_id 정보를 서버 측에서 보관할 수 있게 되어
더욱 안전하게 관리할 수 있게 된다.
단점으로 시도 때도 없이 세션이 생성.
서버에 저장되는 세션이 많아지면 많아질수록 세션을 만들고, 찾는 과정에서
처리를 요구하는 부하와 저장 공간이 추가적으로 필요하게 된다.
로그인한 유저의 정보를 유지시키고 싶다.
그런데 근데 유저 아이디 값을 쿠키로 저장하니 변경이 가능해서 안전하지 않고
서버 쪽 세션을 만들어서 저장해 그 키 값을 쿠키로 내려주니 너무 많은 저장공간이 필요했습니다.
공개된 정보를 내려주되 이 값이 변조되지 않았다는 것을 증명하는 암호문도
같이 내려주면 되지 않을까?
내용의 부분을 데이터 포맷에서 많이 사용되는 JSON 형식으로 내려주기로 했다.
그래서 Json Web Token 이다.
웹 통신 상 빈칸이라던지 특수기호 등의 데이터는 손실이 될 가능성이 있다.
이런 손실 가능성이 있는 형식의 데이터를 안전하게 전송하기 위해서는 Base64라는 인코딩 방법을 사용한다.
인코딩이란,
정보의 형태나 형식을 여러가지 목적에 따라 (저장 공간, 데이터 표준화, 보안, 퍼포먼스 등)을 위해서
다른 형태나 형식으로 변환하는 처리 방법 의미.
-> 손실 없이 데이터를 주고 받기 위해서는 base64로 인코딩한다는 의미이다.
토큰 : 특정 데이터를 들고 다니는 객체
헤더 : 토큰의 종류와 사용된 알고리즘
내용 : 토큰을 통해 클라이언트에게 저장/전달해주고 싶은 정보
서명 : 인증하기 위한 증명서
헤더와 내용은 JSON 형식이지만 이를 안전하게 전달하기 위해서
각각 base64 형태로 인코딩 한다.
인코딩 한 헤더와 내용을 특정 암호화 알고리즘을 통해서 암호화시켜 서명으로 사용.
그렇게 되면 서명 부분을 복호화 했을 때의 값이 헤더 + 내용과 일치한다면
올바른 토큰이라는 것을 증명할 수 있음
이를 자가 수용적 (self-contained)라고 표현한다.
JWT는 필요한 모든 정보를 자체적으로 지니고 있다.
토큰에 대한 기본정보(헤더),
전달하고 싶은 정보(내용),
토큰이 검증됐다는 것을 증명서까지 포함(서명)
이런 모든 정보를 들고 있다면 굳이 세션이란 데이터를 서버에 저장하거나
쿠키를 통해서 위변조 됐는지 걱정할 필요도 없이 JWT 하나만을 이용해서 정보를 안전하게 보낼 수 있을 뿐더러
이 정보가 위조 됐는지 변조 됐는지 여부를 서명을 통해서 할 수 있게 되는 것
iat : issue at (언제 발행 되었느냐)
sub : 누군가로부터 토큰을 발행했는지, 누구로부터 토큰을 발행 해줬는지에 대한 정보 (특정 유저 아이디를 적는 것이 관례)
내용을 변경하게 되면 서명 부분이 바뀌는데
왜 그러냐면 앞에 있는 곳이 일치하는가를 증명하는 증빙서류이기 때문
체크한 부분이 비밀키.
특정키값을 이용해서 암호화하고 복호화한다.
지금 암호화하는 기법은 대칭키 암호화 알고리즘의 하나로 HS256이라는 방식이여서
키를 암호화하고 복호화 할 수 있다.
JWT에서도 마찬가지로 Private Key와 Public Key를 이용해서 암호화 복호화 할 수도 있다
OAUTH란?
아이디와 비밀번호를 직접 넘겨주지 않고
유저의 권한 중 넘겨주고 싶은 것만 설정해서 전달해주는 방법
Resource Owner(유저) -> 브라우저
Resource Server(페이스북)
Client(스코르타코딩클럽) -> 역할군 명칭. 원래는 웹 서버이다.
신뢰하는 client에게 Resource Server가 access_token 이라는 것을 발급해서
client에게 전달한다.
-> 이를 코드 교환(code exchange)단계라고 한다.
authorization_code : client와 Resource Server만 이용하는 비밀값
--2번째 시간
어느 범위까지 가져올 것인지에 대한 설정을 scope(범위) 라고 한다.
Refresh Token
access_token
: 수명이 있음.
해당 리소스를 무제한 접근하는 권한을 주면 위험하기 때문
수명이 끝난 토큰을 가지고 요청하면 expired_token이라는 에러를 표시해줌
access_token은 매 요청시마다 함께 하는 토큰이여서 네트워크 상에서 유실될 가능성이 매우 높음
즉, 토큰이 한 번 털리면 유저 데이터가 털린다.
보완하고자 수명시간을 짧게 두면 로그인을 자주 해야되는 불편함 발생
따라서,
매번 통신할 때 주고 받는 access_token은 유호기간을 짧게 두되,
access_token을 새롭게 받을 수 있는 refresh_token을 주겠다.
그러면 매번 통신할 때 털리는 access_token은 1시간만 유효하므로 그나마 안전하고,
새롭게 로그인하기 귀찮을 때는 refresh_token을 쓰면 된다! 라는 결론
즉 refresh_token은 매 통신마다 보내는 것이 아니고
몰래 브라우저상에 숨겨 놓은 상태에서 access_token은 계속 쨉쨉이로 던지는 방식
REST API키 -> client_id
Redirect URL -> 예전에 설정했던 코드 돌려주는 것인 callback_url를 설정하는 것
본인이 만들 서버의 callback_url입력
본인이 만든 서버에서 authorization_code를 입력 받아서 코드 exchange를 통해서
access_token을 받아올 위치
카카오 로그인은 특이하게 client_secret을 기본으로 설정해두지 않음
대신 선택으로 제공
response_type=code -> 코드라는 것은 authorization_code 받식을 사용한다는 것을 의미
