인증 (Authentication)

로그인 절차에서 정확한 이메일/비밀번호 조합을 입력했는지 확인하는 과정!

왜필요할까?

• 우리 서비스를 누가 쓰는지? 어떻게 사용한느지? 추적이 가능하도록 하기위해서 필요하다.

인증에 필요한것

• 아이디, 이메일, 비밀번호(제일중요)등등

비밀번호는 어떻게 관리해야하는가?

비밀번호와 같은 개인정보는 암호화되지 않고 개인정보처리 시스템에 저장되거나 네트워크를 통해 전송될 경우, 노출 및 변조 등의 위험이 있으므로 암호화 등의 안전한 보호 조치가 제공되어야한다.

암호화는 어떻게 할까?

단방향해쉬

• 본래 해쉬(hash)함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용한다.
• '1234'를 SHA-256 해싱하면 다음과 같다.
  03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4
• 결과만 봐서는 당장 식별이 불가능하므로 완벽해보인다.
• 하지만 같은 알고리즘으로 '1234'를 다시 해싱하면 항상 같은 결과가 도출된다

레인보우 테이블 어택 : 경우의수를 모두 해시값으로 만들어서 판매하는 서비스
단방향 해쉬는 이 같은 허점이 있기 때문에 이 것을 보완하고자 salting과 ket stretching이라는 아이디어가 생겨났다.

SALTING & KeyStrectiching

• 단순해쉬값이 해킹에 쉽게 노출되기 때문에 Salting이라는 아이디어가 생겨났다.
• 입력한 비밀번호와 임의로 생성한문자열(Salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법이며
  해시값과 소금(Salit)값을 같이 저장한다.
• 솔팅및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는것이 키 스트랫칭이다.

bcrypt

Salting과 Key Stretching 대표적 라이브러리

• 앞서 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리이다.

• 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게적용가능하다.

• bcrypt는 hash결과 값에 소금값과 해시값 및 반복 횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB 설계를 복잡하게 할 필요가 없다.

• bcrypt를 통해 해싱된 결과 값(digest)의 구조는 아래와 같습니다

  

인가 (Authorization)

사용자가 서버에 요청을 보내면 인증과정을 거쳐 확인된 사용자가 맞는지 확인하는과정

HTTP의 가장 중요한 특징들
요청과 응답
저장하지않는 성질 : 그래서 요청들이 다 독립적이여서 로그인정보도 매번 보내야함

HTTP는 Stateless한데, 서버에서 요청을 받으면 사용자가 로그인 한 상태인지 어떻게 알수 잇을까?

• 매 HTTP요청마다 headers를 활용하여 사용자가 인증 절차를 거친 사용자임을 증명하는 정보를 담아서 보내는 방법이다.

Traditional Way

기존의 인증/인가 처리방법

기존방식의 단점

서버가 여러개있을경우 세션은 하나의서버에 저장되어있기때문에 나머지는 서버는 세션에 관한 정보가없다.

JSON Web Token(JWT)

헤더

• 토큰의 타입과 해시알고리즘 정보가 들어간다.
• 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록된다.
• 예시 -{"alg": "HS256", "typ":"JWT"}

내용

• exp와 같이 만료시간을 나타내는 공개 클레임이다.
• 클라이언트와 서버간 협의하에 사용하는 비공개 클레임이다.
• 그 외 어떤 내용이던 상관없이 추가 가능하다.
• 위의 두가지 요소를 조합하여 작성한 뒤 BASE64 인코딩하여 두번째 요소로 위치한다.
• 예시 -{"user-id":1, "iat":1539484983}

서명(중요)

• JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분이다.
• BASE64URL 인코딩된 hearder와 payload 그리고 JWT secret(별도 생성)을 서버에서 생성한 JWT가 맞는지 확인한다.
• 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 보면된다.
• 주의할 점은 hearder와 payload는 BASE64 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안된다.

실제예시

JWT 활용하기

기존방식의 단점을 어떻게 보완해서 최근에 사용되고 있을까?

기존은방식은 첫번째 서버에서 발행한 세션정보를 나머지서버는 모르고있는 단점이 있었지만
JWT가 보완해준다. 서버끼리 SECKRET_KEY만 있으면 인증할수있다.