TIL 33 | 인증과 인가

인증과 인가

인증(Authentication)은 무엇이고 왜 해야할까?
Authentication은 유저의 identification을 확인하는 (= 유저의 아이디와 비번을 일치 ) 절차이다.
이를 통해 회원을 식별하고 누가 어떻게 쓰는지 추적, 데이터를 얻을 수 있다.
인증에 필요한 것은 아이디, 이메일주소,비밀번호 등이 있다.

로그인 절차
1. 유저 아이디와 비번 생성
2. 유저 비번 암호화 해서 DB에 저장.
3. 유저 로그인 -> 아이디와 비밀번호 입력
4. 유저가 입력한 비밀번호 암호화 한후 암호화되서 DB에 저정된 유저 비밀번호와 비교.
5. 일치하면 로그인 성공
6. 로그인 성공하면 access token을 클라이언트에게 전송.
7. 유저는 로그인 성공후 다음부터는 access token을 첨부해서 request를 서버에 전송함으로서 매번 로그인 해도 되지 않도록 한다.

1. 비밀번호 관리 (법규상의 강제)

국가에서 권고하는 상용 암호와 알고리즘을 이용하여 개인정보를 암호화하여 관리한다.
그렇다면 비밀번호를 어떻게 관리해야 하는가?
Database에 저장시, 유저의 비밀번호는 저대 그대로 저장하지 않는다.
이것을 만든 개발자/내부 인력 또한 개인정보를 알아볼 수 없게 암호화하여 복원할 수 없도록한다.

2. 암호화는 어떻게 할까?

1) 단방향 해시(복구화 불가능)

비밀번호 암호에는 단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰인다.
양방향 암호화는 암호화된 데이터에 대한 복호화가 가능한 암호화 방식.
단방향 암호화는 양방향 암호와는 다르게 암호화된 데이터에 대한 복호화가 불가능한 암호화 방식.
단방향은 하나의 값이 들어가면 하나의 값이 나오는 (하나의 인풋, 하나의 아웃풋)
다만 아웃풋이 나왔으면 역으로 인풋을 유추할 수 없다.
하지만 허점이 있어서 rainbow table이라는 것이 생겨서 해시값을 유추하는 사이트가 존재하게 되었다.

2) salting & keyStretching

단순 해쉬값이 해킹에 쉽게 노출되기 떄문에 salting이라는 아이디어가 생겨났다. (해킹 시간 벌려고)
단방향 해쉬 함수의 취약점들을 보안하기 위해 일반적으로 2가지 보완점들이 사용된다.
Salting? 입력한 비밀번호와 임의로 생성한 문자열(salt)를 합쳐서 해싱한다. (물론 이때에 비교를 위해 해시값과 소금값을 같이 저장)
keyStretching? 해싱한값을 계속/여러번 해싱하여 복원하기 어렵게 한다.

Bcrypt
Salting & keyStretching대표적 라이브러리(오픈소스/코드 덩어리)
앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적 라이브러리이다.

3. 인가는 무엇인가?(Authorization)

사용자가 서버에 로그인하고나서 추가적인 어떤 기능을 사용할 때 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차 이다.

Authorization 절차
1. Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
2. 유저가 request를 보낼때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
7. 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.

stateless 성질이 있어서 헤더에 메타데이터를 보내서 확인한다.
토큰은 발급되는 시점? 처음로그인 성공 했을 때 BE가 보내준다.
FE에서 가지고 있다가 다시 다른 기능이 요청될 때, 같이 요청을 보낸다.

4. JSON Web Token (JWT -> Token)

앞서 언급했듯이 유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.
그러면 서버에서는 access token을 복호화 해서 해당 유저 정보를 얻게 된다.

예를들어,
access token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E 를 복호화 하면 다음과 같은 정보를 얻는다.

	
        {
		    user_id = 1 
		}

복호화해서 얻은 유저 아이디를 통해 해당 유저가 누군지 알 수 있다.
또한 이런 절차의 목적은 해당 유저가 매번 로그인 하지 않도록 하는 것이다.

access token을 생성하는 방법은 여러가지가 있는데, 그 중 가장 널리 사용되는 기술중 하나가 바로 JWT(JSON Web Tokens)이다.
JWT는 말 그대로 유저 정보를 담음 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것이다.

5. JSON Web Token 내부

JSON Web Token는 Header , Playload (data), Signature(verification)으로 이루어져 있다.

1. 헤더
(암호화하지않았기 때문에 디코딩 하면 보인다)
헤더에는 토큰의 타입과 해시알고리즘 정보가 들어간다.
헤더의 내용은 BASE64방식으로 인코딩해서 JWT(암호화와 다름)의 가장 첫 부분에 기록된다.

2. 내용
(암호화하지않았기 때문에 디코딩 하면 보인다)
내용에는 exp와 같이 만료시간을 나타낸는 공개 클레임
그리고 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
두가지 요소를 조합 / 작성, BASE64 인코딩하여 두번째 요소로 위치

3. 서명
우리 사이트라는 것을 알려줘야 하는데
FE가 가져왔을 때 BE에서 다시 까봐서 몇번 유저이지, 우리사이트가 맞는지 확인하는 것이다.