[Back-end] 인증&인가

sumin·2022년 6월 16일
💡 강의 노트와 세션 영상을 들은 후 다시 복습하기 위해 기록!!

📌 1. 인증(Authentication)

  • 회원가입과 로그인을 말함
  • 인증에 필요한 것들 아이디,이메일주소, 비밀번호 등.. 있고
    가장 중요한 것은 비밀번호이다
  • 비밀번호는 암호화 되어 저장됨
  • 사용자가 맞는지 확인하는 과정

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

✔ 비밀번호 Password

비밀번호는 DB에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함

단방향 해쉬 함수(one-way hash function)

  • 단방향으로 변경함
  • 암호화된 데이터가 무엇인지 모르게 만들어 준다
  • 복호화가 불가능하다

💡 비밀번호 어떻게 구분할 수 있을까?

  • 암호화된 값을 복호화하지 않고
    들어오는 값(유저가 입력한 비밀번호)을 암호화하여
    DB에 저장된 데이터(암호화된 비밀번호)와 비교한다

동일한 평문(원본 비밀번호)는 암호화 될 때마다 똑같이 암호화가 되게 만들어 준다
그래서 암호화하는 방식을 각각의 사이트마다 다르게 하기 위해서 SECRET KEY를 준다
(SECRET KEY, SALT 등)

  • 비밀번호와 임의로 생성한 문자열(Salt)
  • Salt + Hash = Salting

✔ Bcrypt

  • Salting & Key Stretching 대표적 라이브러리
    bycrypt는 hash 결과값에 소금값 + 해시값 + 반복 횟수를 같이 보관
    (반복 횟수는 salt를 얼마나 뿌릴 것이냐는 뜻 - 많아지면 많아질수록 계산시간이 늘어나기 때문에 기본 10번 정도 반복하게 설정한다)

구조 : 알고리즘 + 알고리즘 옵션(반복 횟수) + 소금값(항상 바뀌는 값) + 해싱한 비밀번호


📌 2. 인가(Authorization)

  • 사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정
    (인증 후 사용자가 내부 서비스에 적합한 사용자인지 확인하는 과정 - 판매자, 구매자 등등)
  • http의 stateless한 성질 때문에 각각의 req와 res마다 인증하는 정보, 인가하는 정보를 넣어서 요청해 주어야 한다

💡 서버는 사용자가 로그인했을 경우, 로그인했다는 것을 어떻게 알 수 있을까?
http header에 메타데이터를 보내서 확인함 -> JWT(JSON Web Tokens)
토큰 기반 인증방식!

✔ JWT(JSON Web Tokens)

  • 유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다
    구조 : 헤더(header) + 내용(payload) + 서명(signature)

헤더(header) : 토큰의 타입, 해시알고리즘 정보가 들어감 - 양방향/복호화 가능
예시) {"alg": "HS256", "typ" : "JWT"}

내용(payload) : 식별할 수 있는 정보, exp와 같이 만료시간을 저장 - 양방향/복호화 가능
예시) {"user-id": 1, "exp" : 1539517391}

서명(signature) : JWT가 정상적으로 암호화가 되었는지, 원본 그대로라는 것을 확인할 때 사용하는 부분 - 단방향/복호화 불가능
-> 계약서의 위변조를 막기 위해 서로 사인하는 것고 같다고 보면 된다

0개의 댓글