그 전 시간에는 HTTP를 비롯한 네트워크의 성질을 알아보았다.
이번엔 HTTPS의 작동방식과 여러 인증방식을 학습해보겠다.
HTTP(S)는 무상태성을 지닌다. 어? 그러면 장바구니 이런데 담겨져있는데 새로고침해도 어떻게 상태가 남아있는 걸까? 여기서 우리에게 익숙한 쿠키가 나온다.
서버에서 클라이언트에 영속성있는 데이터를 저장하는 방법, 서버는 클라이언트의 쿠키를 이용하여 수집 가능
즉, 서버가 클라이언트에 특정한 데이터를 저장하고 보낼 수 있는 특징이 있다.
또 데이터를 저장한 이후 아무 때나 데이터를 가져올 수는 없다. 데이터를 저장한 이후 아래와 같은 특정 조건들이 만족되어야 다시 가져올 수 있기 때문
'Set-Cookie':[
'cookie=yummy',
'Secure=Secure; Secure',
'HttpOnly=HttpOnly; HttpOnly',
'Path=Path; Path=/cookie',
'Doamin=Domain; Domain=codestates.com'
]
그래서 쿠키를 설정할 때, 위 쿠키옵션(조건)들을 알아둬야한다.
Domain
http://www.localhost.com:3000/users/login
localhost.com
Path
http://www.localhost.com:3000/users/login
/users/login
/users
로 설정됐어도 /users/login
에 쿠키 전송 가능MaxAge or Expires
Secure
HttpOnly
document.cookie
를 이용한 JS 접근으로 XSS 공격 취약SameSite
Lax
: GET 메소드에 대해서만 쿠키를 전송 가능Strict
: same-site
인 경우에만 쿠키를 전송 가능None
: 모든 메소드 요청에 쿠키 전송 가능. 다만 쿠키 옵션 중 Secure 옵션이 필요same-site
는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우, 이 중 하나라도 다르다면 Cross-Origin으로 구분서버에서 이러한 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie
라는 프로퍼티로 쿠키를 담아 전송
이후 클라이언트에서 서버에게 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 서버에 쿠키를 전송
쿠키를 활용하여 로그인 상태를 유지하는 애플리케이션을 구현해보자!
이번엔 axios로 데이터를 가져와보겠다.
이 순서대로 구현해보자 오고가는 느낌을!
서버가 클라이언트에 유일하고 암호화된 ID를 부여, 서버에 중요 데이터 관리
세션 인증 방식에서 취약한 부분을 보완해 나온게 토큰, 그중 대표적인 토큰인 'JWT'에 대해서 알아보자!
해시 함수(Hash Function)을 사용하여 암호화를 진행, 복호화가 가능한 다른 암호화 방식들과 달리 해싱은 암호화만 가능
즉, 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해서 사용되는 단방향 암호화 방식
즉, 암호화 가능이고 매번 같은 결과값을 산출함 어디서? 여기서
비밀번호 | 해시 함수(SHA1) 리턴 값 |
---|---|
‘password’ | ‘5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8’ |
‘Password’ | ‘8BE3C943B1609FFFBFC51AAD666D0A04ADF83C9D’ |
‘kimcoding’ | ‘61D17C8312E8BC24D126BE182BC674704F954C5A’ |
비밀번호 | 해시 함수(SHA1) 리턴 값 |
---|---|
‘password’ + ‘salt’ | ‘C88E9C67041A74E0357BEFDFF93F87DDE0904214’ |
‘Password’ + ‘salt’ | ‘38A8FDE622C0CF723934BA7138A72BEACCFC69D4’ |
‘kimcoding’ + ‘salt’ | ‘8607976121653D418DDA5F6379EB0324CA8618E6’ |
결론: 클라이언트에서는 HTTPS를 먼저 사용해 사용자의 중요 정보가 중간에 탈취 안되게 하고, 서버는 요청 받은 정보들을 그대로 DB에 저장하지말고 해싱을 거쳐 저장하기.
토큰: 동전인데 오락실에서 동전을 넣어 게임 플레이 권한을 획득하는 코인이라든지 아니면 대중교통 이용권같은 코인들을 영어로 토큰이라고 부름
세션 기반 인증은 서버 or DB의 세션객체, 클라의 세션 id를 비교해 인증하는 거 였는데, 매 요청마다 DB를 둘러봐야하니 부담이 커 클라이언트에서 바로 처리할 순 없을까? 에서 고안된 인증 방식이다.
유저 정보를 암호화 하고 클라이언트에 담을 수 있는 인증 방식
웹에선 JWT (JSON Web Token)가 많이 쓰임!
Json 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰
1. 액세스 토큰: 정보에 접근 가능한 권한 부여하는 토큰
2. 리프레시 토큰: 만료된 액세스 토큰을 새걸로 발급해주는 토큰
액세스 토큰만 있어도 권한이 있도록 만들어 준다. 하지만 오래 갖고있으면 보안상 취약해지기 때문에 사용기간이 짧다.(로그아웃, 창 닫기, 시간 등)
리프레시는 이러한 액세스의 짧은 시간에 대한 편의성을 증대시키기 위해 만들어졌다. 즉, 리프레시 덕분에 만일 로그인할 때 액세스를 받아 권한이 생기고, 리프레시도 받아 우리가 창을 닫아도 다시 창을 키면 로그인 돼있게 만들어졌다.
어떤 토큰인지, 어떤 알고리즘으로 시그니처를 암호화하는지 적혀있음
'base64'방식으로 인코딩
예시:
{
"alg": "HS256",
"typ": "JWT"
}
// HS256이라는 알고리즘과 JWT인 토큰임!
말 그대로 서버에 활용될 유저 정보가 담겨져 있음. 권한, 개인정보 등을 담을 수도 있음
근데 디코딩이 쉬운 'base64'방식으로 인코딩 되기에 민감한 정보는 X
예시:
{
"sub": "somInformation",
"name": "phillip",
"iat": 151623391
}
// HS256이라는 알고리즘과 JWT인 토큰임!
'base64'방식으로 인코딩된 첫번째, 두번째 부분이 완성됐으면 서버의 비밀키(해시의 salt같은)와 헤더에서 지정한 알고리즘으로 해싱
서버의 비밀키가 가장 중요
예시: HMAC SHA256 알고리즘(암호화 방법중 하나)을 사용
HMACSHA256(base64UrlEncode(Header) + '.' + base64UrlEncode(Payload), secret)
이로써 누군가 권한을 속이기 위해 알아낸 Header와 Payload를 이용해서 토큰을 위조하더라도, 서버의 비밀 키까지 정확하게 알고있지 못한다면 전혀 다른 Signiture가 만들어지기 때문에 서버가 해당 토큰이 올바르지 않음을 확인 가능!
"아 우리가 발급해준 토큰이 맞네!"
라는 판단이 될 경우, 클라이언트의 요청을 처리한 후 응답을 보내준다.1. Statelessness & Scalability (무상태성 & 확장성)
2. 안정성
3. 어디서나 생성 가능
4. 권한 부여에 용이
JWT인 토큰 인증 방식을 구현해보자!
시작하기에 앞서 salt같은 비밀 키를 설정해 복호화되기 어렵게 만들기 위해 .env에서 환경 변수를 설정
왜 env 이렇게 쓰는거임?!?!? 1. git에 안올라가게(gitignore) 2. 하드코딩 방지
index.js
에서 발급받은 https 인증서를 해당 과제 디렉토리에 복사 후
# mkcert 설치 후
mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1
index.js
에서 CORS 및 세션 옵션을 설정
// 메서드는 GET, POST, OPTIONS를 허용
app.use(
cors({
origin: "http://localhost:3000",
methods: ["GET", "POST", "OPTIONS"],
credentials: true,
})
환경변수(비밀키)로 토큰 발행
// ...
generateToken: async (user, checkedKeepLogin) => {
const payload = {
id: user.id,
email: user.email,
};
let result = {
accessToken: sign(payload, process.env.ACCESS_SECRET, {
expiresIn: '1d', // 1일간 유효한 토큰을 발행합니다.
}),
};
// ...
rediect: 받은 요청을 다시 돌려주는 것, 여기서는 userinfo
로 돌려주어 유효한 토큰인지 확인했음!
인증을 중개해주는 메커니즘을 가진, 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜
Resource Owner
: 사용자이며 정보 제공자Client
: Resource Owner
를 대신하여 보호된 리소스에 액세스하는 애플리케이션Local Server
: Client
의 요청을 수락하고 응답할 수 있는 서버Resource Server
: 사용자의 정보를 저장하고 있는 서버Authorization Server
: 인증을 담당하고 있는 서버이자 Access Token
을 발급하는 인증 서버Authorization Grant
: Client
가 Access Token
을 얻는 방법을 의미, 다음과 같은 방법들이 주로 사용된다.Authorization Code
: Authorization Grant
의 한 타입으로 Access Token
을 발급받기 위한 Code를 의미Access Token
: 보호된 리소스에 액세스하는 데 사용되는 인증 토큰. 이 Access Token
으로 이제 Resource Server
에 접근 가능Refresh Token
: 발급받은 Access Token
이 만료될 시 Refresh Token
을 통해 새로운 Access Token
을 받급 받기 가능!위에서 봤던 Authorization Grant
의 방법들을 사용하여 인증토록 한다.
Authorization Code Grant Type
Authorization Code
를 받아Authorization Code
를 통해Access Token
을 받는 방식
액세스 토큰이 사용자나 클라이언트에 나타나지 않아 누출 가능성 ⬇️
Refresh Token Grant Type
위 방법으로 액세스 토큰을 받은 후 리프레쉬 토큰에 관련된 방법이다.
Access Token
이 만료된 경우Refresh Token
을 활용해 새로운Access Token
으로 교환하는 데 사용됨
사용자와의 추가 상호 작용 없이 계속 유효한 액세스 토큰 발급 가능
OAuth 서버는 구축되어있고 클라에서 OAuth 인증 방식을 구현해야한다! 이번엔 깃헙만 해보는 거다!
⭐️깃헙, 네이버, 카카오, 페북 등 연동할 때 다 다양한 데이터 형식을 가지고 있어 ⭐️꼭꼭 뭐가 응답으로 데이터가 들어오고 어떻게 가공할지 알고 코드 짜자!!@!@!@@!
mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1
https://www.oauth.com/oauth2-servers/accessing-data/create-an-application/ 로 가서 페이지 URL이랑 Authorization callback URL 등록해서 깃헙에 내 앱 등록하기
도메인/?code=~~
)이 필요 GitHub App에서 제공하는 Client ID 및 Client Secret의 정보를 채워 넣어야 함!
서버에 .env.example 파일이 있고, 파일명을 .env로 수정하고, 파일 안에 CLIENT_ID와 CLIENT_SECRET 정보를 담아주세요.
복습하자!
해쉬/토큰 레퍼런스