인증과 인가와 인증의 방법

---

https://youtu.be/y0xMXlOAfss

 

---

인증 : 식별 가능한 정보로, 서비스에 등록된 유저의 신원을 입증하는 과정

인가 : 인증된 사용자에 대한 자원 접근 권한 확인

 

---

게시판 서비스로 예를 들어서

 

- 글을 쓰려면 회원가입을 하고 로그인을 한다, 이게 인증

- 회원가입과 로그인을 하면서 글을 쓸 수 있는 권한을 획득함, 인가도 포함됨

- 다른 사람의 글을 수정할 수 없다, 인가가 적용이 된 개념

 

===

자원 : 글을 쓰는 기능, 글을 삭제하는 기능

인증과 인가 : 자원을 적절한/유효한 사용자에게 전달/공개 하기 위한 방법

 

===

그러므로 선행되는건 인증

5가지의 방법이 있다

 

===

클라이언트와 서버는 HTTP로 소통을 한다,

무상태성(Stateless)가 중요 : 서버는 클라이언트의 요청과 다음 번의 요청의 연관관계가 없다고 생각함.

 

===

1.Request Header

API가 구축되고, 회원가입이 된 상황에서,

ID와 password를 앞에 달아주기만 해도

브라우저가 URL에 있는 ID와 password를 파싱을 하고 요청헤더의 Authorization에 넣어서 보내줌

그럼 서버가 DB체크하고 DB에 실제로 값이 있으니까 OK

 

문제점 : 사용자가 매번 로그인을 계속 해줘야 한다

글을 쓸 때

다쓰고 수정할 때

인증요청을 매번 해야해

 

이걸 해결하고 싶어서 브라우저의 힘을 빌림

 

===

2.Browser 활용하기

Browser에 있는 Storage의 힘을 빌림

Storage는 Local Storage, Session Storage, Cookie도 될 수 있는데 Cookie로 설명

 

쿠키에 사용자 ID PW 집어넣음

사용자가 인증이 필요한 요청을 할 때 같이 그냥 넣어서 보내줌

 

문제점 : Storage에 raw하게 사용자의 정보가 노출돼 있으니까 가져갈 수가 있다

클라이언트가 서버보다 상대적으로 보안에 취약하다

 

이 문제점을 해결하기 위해, 보안을 향상하기 위해 서버에 도움을 요청

 

===

3.Session 활용하기

처음에 로그인 요청을 보내고, 그걸 바탕으로 서버는 DB검증 완료하고 

->아까 같으면 원하는 자원을 바로 클라이언트로 줌

=>이제 세션이라는 개념을 도입

 : 인증된 사용자의 식별자와 랜덤한 문자열로 session id를 만들어서 응답의 헤더로 넘겨주고(Set-Cookie:) 클라이언트가 저장할 수 있도록 만드는 것

세션 장점 : 

- 클라이언트 쪽에서 사용자의 raw한 데이터를 갖고 있지 않으니 해커가 정보를 가져가도 크게위험하지 않다

- 세션에 만료기간을 정할 수 있어서 만료기간이 지나게 될 경우엔 해커가 가져가도 유효하지 않다

- 세션의 관리를 서버자체에서 하고 있어서 탈취가 된 세션은 서버에서 삭제해버리면 유효하지 않다

 

세션 문제점 : 

- 서비스가 잘돼서 서버를 여러대두면 로드밸런서도 생기는데 한번 인증을 해서 Session을 받았을 때 그 다음 요청은 세션으로만 요청을 하게됨(=DB까지 찍을 필요가 없다). 이 상황에서 유저가 두번째 인증이 필요한 요청을 하면 그때 로드밸런서가 다른 서버에 요청을 전달하게되면?

서버 하나하나 자체에서 세션을 관리하고 있어서 생기는 문제

이 문제는 세션스토리지 라는것을 둬서 해결함 서버들이 관리하는 세션들을 한곳에서 관리함

 

근데 얘도 문제가 있어

사용자가 많아지면 계속 쏴서 터짐

 

===

지금까지

로그인성공

->사용자를 위해 쿠키나 브라우저의 힘을 빌림

->보안상 문제로 서버까지 와서 인증인가를 하게했더니 그래도 문제가 있다

 

===

클라이언트, 서버, 세션저장소

이 셋 에게 한번씩 사용자의 정보 상태를 관리할 수 있게 했음.

다 문제가 있었어

 

이유 : 셋 간에 통신할 때 사용하는 HTTP와 서버 자체가 지향하는 REST API가 무상태성을 기초로 하기 때문

근데 앞선 세가지는 다 사용자의 상태를 자기가 갖고 있었어 stateful해

 

두 패러다임이 충돌하고 있어. 그걸 해소해야 문제가 해결될 것 같아

 

===

TOKEN

지금 양쪽 애한테 한번씩 사용자의 상태를 맡겨봤어. 남은애는 가운데의 화살표한테 맡겨보자

 

요청과 응답의 컨텐츠 안에 사용자의 상태를 담아보자 그걸로만 사용자의 인증과 인가를 처리하자

 

그 중에 JWT를 사용할 것

 

(1)시크릿키를 사용해서 JWT를 만들어냄

(2)시크릿키를 사용해서 JWT의 인증과정을 거침

 

이 두개다

 

JWT자체는 해독하기가 무척 쉽다

그래서 JWT내에는 민감한 정보(비밀번호)를 담지 않는다

시크릿키가 중요한만큼 노출되면 JWT도 끝. 시크릿키를 서버 내부에 잘 관리해야한다

 

===

토큰활용1

맨 처음은 똑같다

(1)요청을 보내면 DB체킹

(2)이때 원래같았으면 Session Storage랑 연결이 됐을텐데 그렇지 않고, 시크릿키를 이용해서 토큰을 만들어냄

(3)헤더에다가 넣어서 사용자에게 보냄, 다음부터는 이 키를 이용해서 요청을 보내고 응답을 받는

 

===

토큰활용2

요청이가면 : 토큰이 클라이언트로부터 서버로 넘어간다면

서버는 : 이 토큰의 유효성검사를 본인이 가진 시크릿키로 진행함

유효하지 않으면 버리고, 유효하다면 다음 단계인 사용자 정보를 파악함

 

사용자정보중에 이름이 있으면 그걸로 어떤 유저인지 찾아냄

사용자정보중에 만료시기가 있으면 유효한 토큰이고 어떤 사용자인지도 알겠는데 이미 만료된거야?진행x

사용자정보중에 권한이있으면, 이 사용자는 Admin이네?

 

이렇게 토큰하나에서 다 확인할 수 있다

 

비밀번호같은건 담지 않는다. 디코딩하기 쉽기 때문에

 

시크릿키를 통해서 유효성검사를 통과한 토큰은 인증을 받은 토큰이라는 것

 

===

토큰의 장점 : 

세션같은 경우는 서버가 여러대가 있으면 세션 DB를 따로 둬서 연관성이 있었는데

이젠 로드밸런서가 쏘는걸 각자 자기가 가진 시크릿키로 해독해서 인증을 진행하고 요청을 반환하면 된다

이 장점이 조금 더 나아가서

현대의 서버 시스템에 중요한 확장성과도 연결이 됨

 

3대의 서버가 5대가 되도 똑같이 진행하면 됨

 

===

Refresh Token : 

액세스 토큰이 탈취당하면 해커는 사용자와 똑같은 지위를 갖게 됨, 사용자가 닿을 수 있는 자원에 접근 가능

이를 막기위해 만료기한을 정함.

시간이 지나면 해커도 사용자도 사용할 수 없다

 

(1)로그인 요청을 보내면 보낸 요청에 따라 시크릿 키를 통해 토큰을 만든다

(2)이때 서버가 만드는 토큰은 액세스 토큰과 리프레시 토큰을 한번에 만듦

(3)액세스 토큰은 저장하지 않고 Refresh Token만 따로 저장소에 저장을 하게 됨

(4)이 둘을 한번에 응답의 헤더로 보내서 클라이언트가 둘다 저장을 하게됨

액세스토큰은 사라지고 저장을 하지 않는다는 그림

(5)클라이언트가 액세스 토큰을 사용해서 요청을 보내게됨

(6)액세스 토큰이 만료됐을 경우 요청을 보내면

(사용자는 액세스 토큰이 만료됐다는 모르고 알필요도 없음)

->서버가 만료됐다고 함

->브라우저단에서 액세스 토큰과 리프레시 토큰을 함께 보냄

->서버는 돌아오는 리프레시토큰을 참고해서 DB를 찔러서 이게 맞으면

->새로 갱신한 액세스 토큰을 보냄

(7)클라이언트도 갱신된 액세스 토큰을 사용할 수 있게 됨

 

===

토큰 핵심

토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다

DB를 찌르지 않아도 돼서 효율성이 좋아짐

하지만 토큰도 탈취당할 수 있어, 보안 관리를 해야하는 대상이다

 

===

5.다른 서비스를 통해 인증받기

OAuth

 

===

99.복습

(1)인증

(2)인가

(3)상태를 어디에다 두냐에 따라

- 유저자체 : 본인이 타이핑해서 인증함(매번 힘듦)

- 브라우저에 맡김

- 서버에 맡김

- 토큰(JWT)에 맡김

 

===

100.더 알아보려면, 하나하나가 다 양이 많음

 

보안

 

JWT

 

OAUTH

 

인증 서버 자체를 둬서 인증하는 방법

 

HTTPONLY라는 옵션, 서버에서 클라이언트로 정보를 보낼 때 정보에 달아주는 옵션 : 스토리지에 저장된 정보를 함부로 접근할 수 없게 만드는 옵션

 

Sliding Session과 Refresh Token, 상호보완적인 개념

*Refresh Token은 말이 많음, 위험하다 안위험하다 써야되냐 말아야되냐

 

SSL / TLS1.3

 : 가장 접근하기 쉽고, 가성비가 좋은 보안 방법

 : http's'를 다는 것, 우테코에서 추천하고 미션에도 있음

 

해킹 방법을 알면 적을 알고 싸우는 것

 

===

보안과 사용자의 편의성에 대해 밸런스를 맞추는 과정이었다, 정답이 없는걸 느꼈다

로그인을 자주 하라는건 토큰의 기간을 짧게 잡은 것, 귀찮지만 보안△