인증(Authentication) & 인가(Authorization)

dev_bomdong·2021년 8월 24일
0

Web

목록 보기
8/9
post-thumbnail

인증 (Authentication)

유저의 identification을 확인하는 절차

이 때 인증에 필요한 게 뭐가 있을까? 바로 ID, PW, E-mail등이다.
따라서 인증을 한 마디로 쉽게 말하면 로그인

절차

  1. user의 ID / PW 생성
  2. user의 PW 암호화 후 DB에 저장
  3. user가 ID / PW 입력
  4. user가 입력한 PW를 암호화한 값과, DB에 저장되어있던 암호화된 PW가 일치하는지 비교
  5. 두 값이 일치하면 로그인 성공!
  6. 로그인 성공시 user에게 access token을 발급 (로그인 인증 증명서 같은 느낌)
  7. 이후 user는 server에 access token을 첨부해 request를 보내기 때문에, 계속해서 로그인을 하지 않아도 된다.

비밀번호 암호화

user의 비밀번호는 해킹, 보안 이슈로 인해 암호화된 후 DB에 저장된다.

비밀번호 암호화 방법

일반적으로 단방향 해쉬 함수(one-way hash function)가 쓰인다.

단방향 해쉬 함수

  • 입력값인 원본 메세지를 변환해 암호화된 메시지(다이제스트)를 생성한다.
  • 단방향으로 진행되어 원본 메시지를 알면 암호화된 메시지를 쉽게 알 수 있지만, 암호화된 메시지에서 원본 메시지를 알아낼 수 없다. 따라서 해킹을 막기 위한 암호학적 용도로 사용된다.

Salting & KeyStretching

단방향 해쉬 함수는 미리 해쉬값들을 계산해 놓은 테이블(Rainbow Table)을 활용해 해킹될 수 있다는 단점이 있다. 이러한 단점을 보완하기 위한 것이 Salting과 KeyStretching!

Salting

입력한 비밀번호에 임의로 생성한 문자열(Salt)를 합쳐서 해싱하고, 이 해시값을 저장하는 방법

ex. pw를 아자아자123 이라고 생성한다면, salt가 합쳐진 해시값
asdfghjkl아자아자123 이 DB에 저장된다.

KeyStretching

단방향 해쉬값을 계산 한 후 그 해쉬값을 또 해쉬 하고, 또 이를 반복하는 것

ex. asdfghjkl아자아자123 를 여러 번 해쉬한다!


Bcrypt

Salting & Key Stretching을 도와주는 대표적인 라이브러리


JWT(JSON Web Tokens)

HTTP의 특징 중 하나인 stateless (이전 상태를 기억하지않는다)에 의하면 user는 로그인이 성공한 뒤에도 매번 로그인을 다시 반복해야한다.

앞쪽의 인증 절차를 소개할 때, 위 문제가 일어나지 않도록 인증이 완료되면 증명서와 같은 access token(암호화된 유저정보)을 발급한다고 했다. server는 이 access token을 복호화해서 유저정보를 얻게된다.

access token을 생성하는 기술중 가장 널리 이용되는 것이 JWT(JSON Web Tokens)이다. 유저 정보가 담긴 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것을 뜻한다.

구조

header. payload. Signature

  • header(헤더) : 암호화X 토큰의 타입과 해시 암호화 알고리즘이 담겨있다.
  • payload(내용) : 암호화X 어떤 유저의 토큰인지, 만료일이 담겨있다.
  • signature(서명) : 유일하게 암호화O 이 토큰이 해당 사이트에서 만든것이라는 것을 확인할 때 사용된다.

인가 (Authorization)

request를 요청하는 user가 권한이 있는지를 확인하는 절차
ex. 넷플릭스 유료회원만 영화를 볼 수 있다 / 회원만 특정 페이지에 접근할 수 있다.

절차

  1. user 정보를 확인할 수 있는 정보를 포함한 access token을 생성한다.
  2. user가 request를 보낼때 생성한 access token을 첨부해서 보낸다.
  3. server에서 user로부터 받은 access token을 복호화 하고, user 정보(ID, PW 등)를 얻는다.
  4. user 정보를 활용해 DB에서 해당 user의 권한(permission)을 확인하다.
  5. user가 권한을 가지고 있음이 확인되면 해당 request를 처리한다.
  6. user가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.
profile
블로그 이사중입니다 https://dev-bomdong.tistory.com/

0개의 댓글