HTTPS
HTTPS는 Hyper text transeper protocol secure socket layer의 약자로 HTTP에 보안을 추가한 것입니다. HTTP객체 내용을 암호화 해 통신하는 것이 특징입니다. 이러한 HTTPS의 특징은 3가지가 있습니다.
- 비대칭성 키를 통한 암호화
HTTPS는 HTTP객체를 암호화 할 때 비대칭성 키를 이용합니다. 비대칭성 키는 암호화 하는 키와 복호화 하는 키가 다른 경우를 말합니다. 비대칭성 키는 대칭키보다 보안면에선 유리하지만 복호화 하는데 시간이 오래 걸립니다. - CA
CA는 인증서를 발급하는 공인된 기관으로 각 브라우저에는 인정하는 CA리스트가 있습니다. - 인증서
인증서에는 서버의 도메인 정보가 들어있어 인증서와 응답 객체의 도메인 정보를 비교하여 응답이 인증서가 인증하고 있는 서버에서 온것인지 아닌지 확인 할 수 있습니다.
쿠키
쿠키는 서버가 클라이언트에게 보내는 4kB이하의 작은 데이터로 http의 stateless로 인한 불편함을 해소하기 위해 만들어졌습니다.
쿠키는 보안 대책 없이 사용할 경우 중간에 탈취당해 내용이 알려질 위험성이 있기에 세션이나 토큰등 보안 대책이 필요합니다. 쿠키는 서버에서 속성을 설정할 수 있습니다. 쿠키의 속성은 다음과 같은 것들이 있습니다.
- MaxAge
앞으로 몇초동안 쿠키가 유효한지 설정하는 옵션입니다. - Expire
언제까지 쿠키가 유요한지 Date를 지정하는 옵션입니다. - HttpOnly
자바스크립트로 브라우저의 쿠키에 접근 여부를 설정합니다.
값이 true이면 자바스크립트로 접근 할 수 없습니다.
값이 false이면 자바스크립트로 접근 할 수 있습니다. - Secure
값이 true이면 https통신에서만 쿠키를 전송 할 수 있습니다.
값이 false이면 http통시에서도 쿠키를 전송 할 수 있습니다. - Domain
해당 domain 서버로만 쿠키를 전송할 수 있습니다. - Path
값이 명시되어 있지 않은 경우 기본값을 '/'을 보고 서버 내 모든 라우팅에 대한 요청에서 쿠키를 전송합니다. 만일 값이 명시적으로 '/users'와 같이 나와 있다면 해당하는 라우팅 포함 하위 라우팅에 대해서까지 쿠키를 전송합니다. - SameSite
cross-site request에 대한 쿠키 전송 여부를 결정하는 속성입니다. 값이 총 세가지입니다.
세 경우다 same-site request에 대해서는 쿠키를 전송합니다.
lax(기본값) : cross-site요청시에는 get요청에만 쿠키를 전송합니다.
strict: cross-site요청시 쿠키를 전송하지 않습니다.
none: cross-site요청시에도 쿠키를 전송합니다.
세션
세션은 쿠키에 정보를 담는 것보다 안전하게 서버쪽에 정보를 저장하고 쿠키에는 서버에 저장된 정보에 접근 할 수 있는 세션ID를 발급하여 통신하는 방법입니다. 쿠키와는 달리 정보가 서버쪽에 저장되어 있다는게 특징입니다. 세션ID는 그냥 전송되는게 아니라 암호화 해 쿠키에 담아 클라이언트에 전송합니다. 이후에 사용자는 로그인 할 필요없이 쿠키속 세션ID를 통해 편리하게 활동을 할 수 있습니다. 만일 사용자가 로그아웃한다면 임의의 의미없는 값을 가진 세션ID를 포함한 쿠키를 전송하고 서버의 세션과 관련한 정보를 삭제해 주면 됩니다. 편리하게 사용할 수 있는 모듈로는 express-session이 있습니다.
토큰
토큰은 세션과 달리 정보를 쿠키를 이용하여 클라이언트에 저장합니다. 그리고 세션에서 사용자 인증을 위해 세션ID와 같은 특별한 값을 서버와 클라이언트 모두에게 저장했던 것과 달리 암호화 키의 알고리즘을 통해 토큰이 유효한지 검사 할 수 있기 때문에 클라이언트에만 저장하면 됩니다. 즉 암호화 키는 서버쪽에 토큰은 클라이언트에 저장됩니다.
발급 및 토큰 사용 순서는 다음과 같습니다.
1. 유저가 로그인 등 사용자 인증을 합니다.
2. 서버는 암호화키를 통해 사용자 정보 등 보내고 싶은 내용을 암호화 하여 보냅니다. 예를 틀어 JWT(json web token)를 이용한다면 header.payload.signature로 보낼 수 있습니다.
여기서 header은 이용하는 hashing알고리즘과 어떤 종류의 토큰인지가 나와 있습니다.
payload에는 클라이언트에 제공하고자 하는 정보가 담겨 있습니다.
signature은 base64로 인코딩된 header와 payload사이에 salt를 삽입한 후 한번더 인코딩한 것입니다.
3. 이런 과정을 통해 발급받은 토큰은 access token, refresh token두가지입니다.
4. access token을 이용하여 서버의 api를 이용합니다.
5. access token이 만료시 refresh token을 이용하여 다시 access token을 발급 받을 수 있습니다.
6. 둘 다 만료시 다시 로그인하여 위 과정을 반복합니다.
OAuth
OAuth는 open authrization의 약자입니다. OAuth를 이용하면 사용하고자 하는 웹앱에 대해서 별도의 회원가입이나 사용자 인증없이 OAuth를 제공하는 기존에 가입한 github, facebook등과 같은 사이트에게 접근 권한을 웹앱에 주라고 요청만 하면 웹앱이 resource server 접근 할 수 있게 함으로써 별도의 인증없이 편리하게 웹앱을 사용할 수 있습니다.
OAuth의 인증 방식은 여러가지가 있지만 authroization code방식을 살펴보겠습니다.
1. 사용자가 웹앱에 웹앱 서비스를 요구합니다.
2. 웹앱은 서비스를 위해 resource server의 자원을 필요로 하기에 접근 권한 허용 페이지로 리다이렉트 합니다.
3. 사용자가 접근 권한 허용 버튼을 클릭합니다.
4. 인증 서버에서 웹앱에게 authorization code를 전송해줍니다.
5. 웹앱은 웹앱의 서버에 autrization code를 전송하고 웹앱은 autrization code를 다시 인증 서버에 전송하고 인증 서버는 웹 앱에게 authrization token을 발급해줍니다. 이 때 refresh token을 같이 발급해줄 수 있습니다.
6. 웹앱은 authorization token을 이용해 접근하고자 하는 정보를 저장하고 있는 resource server에게 api요청을 하여 사용자에게 서비스를 제공합니다.
7. authorization token이 만료되었을 경우 refresh token을 이용해 사용자가 접근권한 허용을 선택할 필요 없이 웹 앱이 알아서 access token을 발급받아옵니다.
8. refresh token마저 만료되면 위 과정을 반복합니다.
