인증 & 인가

 

 

인증에 필요한건 아이디, 이메일주소, 비밀번호등이 있다.

그중에서 비밀번호는 법규상의 강제(국가의 강제) 때문에 따로 관리해줘야 한다.

 

 

비밀번호를 관리하는 방법엔 두가지가 있다. 

 

첫번째는 데이터베이스에 넣을 때 부터 암호화를 하는 것이다. 

데이터베이스에 저장시 개인 정보를 해싱하여 복원할 수 없도록 한다. 

(해싱은 난독화 한다는 것)

 

암호화한 사람도 다시 복구할 수 없게 원상태가 뭔지 알 수 없게 해야한다.

왜냐하면 데이터를 만든 개발자가 해킹을 할 수 있기 때문이다.

 

그래서 암호를 친 사람 본인만 알 수 있도록 관리를 해야한다.

 

<아마존 옆의 자물쇠 모양>

 

두번째는 네트워크 상에서 전송을 할 때 암호화하는 방법 (https)

 

ssl인증서가 적용된 https사용하는 것.

 

인증서를 입혀서 통신을 하면 네트워크 통신자체가 암호화가 된다.

 

 

 

해쉬는 함수여서 하나의 인풋이 있으면 하나의 아웃풋이 있다.

 

해쉬의 특징은 나온 아웃풋을 가지고 인풋을 유추할 수 없다. 즉, 단반향이라는 것이다.(복호화를 할 수 없다)

사람들이 이 특징을 가지고 암호화를 만든 것이다.

 

 

 

해시는 언제 누가 똑같은 값을 넣으면 똑같은 값이 나온다.

 

그 결과 md5, sha-1와 같은 해시함수는 나온지 오래되고 너무 많이 쓰이다 보니 

나쁜 사람들이 슈퍼컴퓨터를 돌려서  노가다를 통해 아웃풋값에 해당하는 인풋값을 다 유추해놨다.

그걸 데이터화 시킨게 레인보우 테이블이다.

 

그래서 보안이 취약해져서 sha-256같은 해시를 쓴다.

 

이를 방지하기 위해서 saulting과 key stretching이 등장했다.

 

 

 

Salting = 랜덤한 어떤 문자열을 붙여주는 것

Key Stretching = 솔트값이랑 합쳐서 해싱을 계속 늘려주는 것

 

결국 풀리지만 이렇게까지 하는 이유는 시간을 벌기 위해서다.

 

 

첫번째는 어떤 알고리즘을 썼는지

두번째는 키 스트레치를 몇 번 했는지

세번째는 솔트값

네번째는 해쉬를 거친 비밀번호

 

* 솔트값이나 키스트레치를 몇번 했는지 알려준다고? 라고 생각할 수 있지만 해쉬된 비밀번호를 모르면 아예 소용이 없다.

그래서 1,2,3,번이 노출된거에 대해 의문을 품지 않아도 괜찮다.

 

 

 

 

인가가 필요한 이유는? http의 특징 때문이다.

Stateless : 성질 단기기억 상실증/ 각각의 통신기록이 저장되지 않는다.

 

각각의 통신기록이 저장되지 않기 때문에 로그인을 했어도 이 사용자가 로그인 했다는 증거를 줘야한다.

 

그 증거가 토큰이다.

 

 

토큰은 너 지금 로그인 잘 됐는데 너가 이 다음에 어떤 요청을 해도 내가 너 로그인 했던거 모르니까

이거 들고와 하고 주는게 JWT(JSON Web Token)다.

 

JWT를 만드는건 백엔드다. 

백엔드가 프론트에게 준다(서버가 클라이언트에게 준다) 그런데 백엔드가 유저한테준다고 하면 이상하다.

왜냐하면 토큰은 프론트가 관리하기 때문에 유저는 토큰이 있는줄도 모르기 때문이다.

 

 

백엔드가 프론트에게 토큰을 주는 방법은?

 

토큰처럼 메타데이터 (데이터에 대한 데이터를 담고 있는 것)는 헤더에 담아서 주고받는다.

 

프론트는 나중에 백엔드에게 토큰 들고있다고 알려줄땐 헤더에 담아서 주면 되는 것이다.

 

 

 

헤더는 토큰에 대한 정의가 들어간다.

 

 

바디(페이로드)는 정말 필요한 데이터를 담아준다. 

1. 로그인한 사용자에 대한 정보 (유저아이디 1번인 김xx씨가 로그인한거다 라는 내용을 이 페이로드에 담는다.) 

2. 토큰은 만료시간

 

1번에서 유의할 점은 user-id와 같은 식별만 가능한 식별자를 넣는다는 것이다.  그렇게 하지 않고 이메일,계정,핸드폰 번호 같은 정보를 넣어놓으면 토큰을 탈취당할 시 매우 위험하기 때문이다.

 

 

 

 

 

헤더랑 내용은 암호화하지 않고 인코딩만 한다.

서명은 헤더와 내용을 담아가지고 다시 암호화해서 붙여준다.

또한 secret이란 값도 같이 들어가 있다.

 

secret는 토큰이 우리가 발급한게 맞는지 확인해주는 것이다.

(만약 왓챠에서 발급받은 토큰이 넷플릭스에서 통과되면 안되니까!)

 

 

서명에도 헤더랑 내용이 들어가니까 어찌보면 중복아닌가? 이렇게하는 이유는?

처음에 로그인에 성공하면 jwt를 백엔드에서 만들어서 프론트엔드에게 준다.

그리고 프론트는 그걸 들고다니다가 로그인이 필요한 기능을 할 때 헤더에 담아서

백엔드에게 준다. 백엔드는 그걸 받아서 다시 복호화한다. 열어서 이 토큰이 우리 유저께

맞는지 체크를 하는 것이다.  그 인증방식이 헤더랑 내용을 합친게 서명이랑 똑같으면

매칭 해주는 것이다. + 시크릿키까지 넣어서 체크

 

이러한 이유로 중복을 하는것이다.