인증과 인가

https://jaeilit.tistory.com/70?category=523178

[인증과 인가

영상 https://www.youtube.com/watch?v=y0xMXlOAfss 인증 서비스 사용 할 수있게 권한을 주는 것 1. 인증하기 - Request Header 2. 인증 유지하기 - Browser (쿠키 등 클라이언트 저장) 3. 안전하게 인증하기 Serv..

jaeilit.tistory.com](https://jaeilit.tistory.com/70?category=523178)

전에도 우테코 테크톡을 보면서 포스팅 한적이 있는 내용입니다.

인증(Authentication)

인증 - 사용자가 누구인지 확인하는 절차이다. ex) 신분확인 등

 

예시)

• 우리회사 직원인가?
• 해당공연 티켓 소유자인가?
• 롯데자이언츠 팬인가?

인가(Authorization)

어떠한 권한이 있는지 확인/부여 하는 절차

 

예시)

• 회장님 -> 모든 부서에 관여 방문 가능
• 사원 -> 해당 업무 관련 부서만 방문 가능

 

• vip 티켓인가? vip석 가능
• 일반 티켓인가? 일반석 가능..

 

인증과 인가는 웹에서는 어떻게 적용될까?

인증 - 로그인 / 회원가입
인가 - 토큰 등 권한 부여

 

인증에도 방식이 있는데요,

 

1. http get 쿼리스트링 방식으로 로그인 id password 를 넘겨줌으로써 회원정보를 받아올수도 있구요

http://xxxxx.com/?id=ponyo&password=1234

2. 서버의 세션id 를 발급받아 클라이언트에 저장하여 요청마다 세션id 를 넣어서 서버에 보내줄수도 있습니다.

 

세션인증방식은 서버는  HTTP 프로토콜 특징 중에서 이전의 요청은 기억하지 못하고 요청에 응답할 뿐 응답을 완료하면 연결을 끊어버리는 무상태성이라는 특징 때문에 사용자의 정보 자체를 서버에서 인증하고 관리하는 방식인데요

 

id password 를 인증이되면 서버 세션에서는 id를 발급합니다.

 

발급한 세션id 는 respone-header 의 set-cookie 에 의해 브라우저 쿠키에 저장되고 http 요청마다 헤더에 쿠키가 같이 실려가게 됩니다.

 

서버는 다시 이 헤더의 쿠키 값을 세션 스토리지의 세션id 와 비교를 통해 검증 합니다.

 

단점은

 

1. 클라이언트가 세션id 를 가지고 있어서 하이재킹에 취약하다는 점

2. 서버 세션 스토리지에 저장하기 때문에 유저가 많아질수록 저장할 데이터가 많아져서 부하가 늘어난다는 점 등이 있습니다.

 

3. JWT

 

소개

json web token 은 세션 인증방식과 다르게 서버에서 세션id를 발급하지도 않으며,

token 의 내용에는 민감한 정보를 저장하지 않으므로 탈취를 당하더라도 세션에 비해 상대적으로 해커에 대한 위험이 낮습니다.

 

구성

json web token 은 헤더 . 페이로드 . 서명 으로 구성되어있는데요,

오른쪽 위부터 헤더, 페이로드, 서명 값

헤더는 sha256 등 서명 알고리즘으로 이루어져있고

페이로드는 토큰에 담을 다양한 종류의 데이터가 들어있습니다.

서명에는 헤더와 페이로드를 서명한 값 입니다.

시크릿 키를 이용해 base64 url 로 인코딩한 헤더와 페이로드를 헤더에 규정된 해싱 알고리즘으로 서명합니다.

 

jwt 인증방식

클라이언트에서 id 와 Password 를 서버로 보내옵니다.

서버에서는 클라이언트에서 받은 id db에서 찾습니다.

db 의 password 값은 해싱되어 저장되어 있을겁니다.

클라이언트에서 받은 password 를 decode 해서 일치하는지 확인합니다.

 

모든 인증이 완료되면 시크릿 키와함께 access token을 발급하여 jwt 토큰을 사용자에게 발급을 해줍니다.

 

이제 클라이언트는 이 jwt token 을 헤더에 넣어 서버에 요청을 하고 서버에서는 token 을 검증하여 사용자 인증을 합니다.

 

장점

1. 헤더와 페이로드를 가지고 서명을 생성하므로 데이터 위변조를 막을 수 있다.

2. 세션과 별개로 jwt 을 서버에 저장하지 않는다.

3. jwt 는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.

4. 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다.

5. 확장성이 우수하다.(DB)

6. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능합니다.

7. OAuth 의 경우 sns 소셜계정을 이용하여 다른 웹 서비스의 로그인을 할 수 있다.

8 모바일 어플리케이션 환경에서도 잘 동작한다.

 

단점

1. 쿠키/세션과 다르게 jwt는 토큰 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.

2. 페이로드 자체는 암호화되지 않기 때문에 중요한 정보를 담지 못합니다.

3. 세션과 마찬가지로 토큰을 탈취 당할수도 있습니다.

 

보안

 

xss 공격과 csrf 공격이 있다.

xss 는 스크립트에 악성코드를 심어놓는 것이고

csrf 는 스팸이라 생각하면 편하다. 모르는 사람이 보낸 메일을 클릭하는 순간 의도치 않게 이상한 api 를 호출하게 한다.

 

사실 가장 중요한 내용은 보안이다.

만약 로그인을 하고 받은 access token 을 해커에게 탈취 당해버린다면 어떻게 될까?

그 해커가 내 행세를 하고 다닐 것이다.

은행이라면 계좌가 털릴수도 있다.

 

이렇게 보안을 위해서 refresh token 을 사용하는데,

 

사용자가 로그인을 하면 서버는 access token 과 refresh token 2가지를 respone 을 해준다.

access token 의 만료기간은 짧게, refresh token 은 그것보다 좀 더 길게 통상 2~3주에서 1달 정도로 하는 편이다.

 

사용자는 로그인 완료됬다는 res 을 받고 이 2개의 토큰을 쿠키에 저장하고 해당 서비스를 이용하면서 인가(권한)이 필요한 서비스에 대해서는 access token 을 서버에 보내게 될 것이다.

 

서버는 access token 을 받고 만료가 되었는지 보고 만료가 됬다면 서버는 클라이언트에게 acess token 이 만료됬다고 알려주고

클라이언트는 refresh token 을 보낸다. refresh token 을 이용해 새로운 access token 을 발급받게 된다.

 

탈취

 

access token 은 탈취 당하면 안되지만 HTTP 하이재킹으로 그럴 수도 있다.

일단 가장먼저 HTTPS 로 통신을 암호화하여 하이재킹을 방어해야한다.

 

또 access token 만료기간을 짧게 설정해서 짧은 시간동안 새 token을 발급받게 하는  것이다. 그럼 해커는 token 을 바뀔 때 마다 계속 탈취해야하거나 사용자 인척 refresh token 을 이용해 새 access token 을 받으러 올 수도 있다..

 

refresh token 이 없다면 access token 이 바뀌었으니 사용자는 계속 로그인을 새로 해야한다.

 

access token 이 탈취당한 상황에서 만료일이 도래해서 새 access token 을 받으러 왔을 때 refresh token에서 access token을 발급해주는 과정에서 서버에서 한번 막아 줄 수 있는 시간적 여유가 생긴다.

 

서버는 새 token을 요청한 사람의 ip 또는 도난 신고 등의 이유로 해커 검증을 할 수있고 새 token 발급을 거절 또는 무시를 할 수있다.

 

또 refresh token 은 서버의 안전한 db 에 저장해놓고 탈취당했다고 판단이 될 경우 토큰을 무효화/삭제 시켜 로그아웃을 강제 시킬 수 있다.

 

클라이언트 토큰 저장

 

클라이언트에 토큰을 저장 할 때 쿠키에 저장하는 것을 추천한다.

 

쿠키에 보관 할때 HTTP only 과 Secure 속성을 걸어주어 사용해야 한다.

Http only 는 브라우저에서 document.cookie 로 접근하는 것을 제한하여 해당 쿠키로의 접근을 막아준다.

Secure 옵션을 true 로 해줌으로써 통신할 때 값 읽기를 방어한다.

 

 

OAuth 2.0

인증을 위한 개방형 표준 프로토콜

 

OAuth 방식을 사용한다면 로그인 등 책임을 서드파티 애플리케이션 (구글, 페이스북, 카카오)에게 위임 할 수 있다.

 

예시로 사용자가 카카오 로그인을 통해 로그인을 했다면 사용자가 넘겨준 토큰으로 카카오 리소스 서버로부터 해당 사용자의 프로필 정보 등을 조회 할 수 있다.