-로그인과 회원가입이다.
(유저의 아이디와 비밀번호를 확인하는 절차다.)
-인증을 하려면 유저의 아이디, 비밀번호를 생성하는 기능도 필요하다.
-인증은 누가 서비스를 어떻게 사용하는지 추적하기 위해서 필요하다.
1.유저의 아이디와 비밀번호 생성한다.
2.유저의 비밀번호 암호화해서 DB에 저장한다.
3.유저 로그인(아이디와 비밀번호 입력)
4.암호화된 비밀번호 유저 비밀번호와 비교한다.
5.일치하면 로그인 성공.
6.로그인 성공하면 access token
을 클라이언트에게 전송한다.
7.유저는 로그인 성공 후 access token
를 첨부한 request를 서버에 전송해 매번 로그인을 하지 않아도 되도록 한다.
-유저의 비밀번호는 암호화가 꼭 필요하다.
암호화를 하지 않을 경우, DB가 해킹을 당하면 유저의 비밀번호도 그대로 노출된다. 내부 개발자나 인력도 유저의 비밀번호를 볼 수 있다.
-비밀번호 암호는 단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰인다.
-통신시 개인정보를 주고받을때 SSL을 적용하여 암호화한다.(HTTPS)
* 단방향 해쉬 함수
-원본 메시지를 변환 후 암호화된 메시지인 다이제스트(digest)
를 생성한다. 암호화된 메시지로 원본 메시지는 구할 수 없기 때문에 단방향성
이라고 한다.
-실제 원본 값이 비슷하더라도 해쉬 함수 값은 완전히 다르다. 이러한 효과를 avalance
라고 한다. 이 효과때문에 비밀번호 해쉬값 해킹이 어렵다.
ex) MD5, SHA-1(둘은 보안취약), SHA-256
단방향 해쉬 함수의 취약점
-원본 값을 같은 알고리즘으로 해싱하면 항상 같은 결과가 나온다. 이러한 점을 이용해 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스인 rainbow table
도 존재한다.
-해쉬 함수는 처리 속도가 매우 빠르기 때문에 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 빠르게 비교해 비밀번호를 추측하는데 긴 시간이 걸리지 않는다.
-실제 비밀번호 + 임의로 생성한 문자열 >>> 저장
-Salting과 해싱을 여러번 반복하는 것
-Salting & Key Stretching 대표적 라이브러리
-다양한 언어를 지원하고 사용이 간편하다.
-hash결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 DB설계를 복잡하게 할 필요가 없다.
-bcrypt를 통해 해싱된 결과 값
-사용자가 서버에 로그인하면 해당 사용자가 맞는지 확인하는 과정
-http의 특징(stateless)때문에 헤더에 메타데이터(JWT)
를 보내서 해당 사용자가 맞는지 확인할 수 있다.
-access token
를 생성하는 기술
-유저 정보를 담은 JSON 데이터를 암호화해서 클라이언트와 서버간에 주고 받는다.
-로그인 성공 후 암호화된 유저 정보가 첨부된 access token
을 복호화
해서 해당 유저 정보를 얻는다. 해당 유저가 가진 권한도 확인할 수 있다.
이를 통해 해당 유저가 매번 로그인하지 않도록 한다.
ex) eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6Mn0.TqNLDeEagjSeV6UozaejHx-xOWuzu_6XPHFRvW76Ong
헤더
-토큰의 타입과 해시 알고리즘 정보가 들어간다.
-헤더의 내용은 BASE64 방식
으로 인코딩해서 JWT의 가장 첫 부분에 기록된다.
-암호화된 것이 아니기 때문에 개인정보를 담아서는 안된다.
ex) {“alg”: “HS256”, “typ”: “JWT”}
내용
-exp와 같이 만료시간을 나타내는 공개 클레임과 클라이언트와 서버간 협의하에 사용하는 비공개 클레임을 조합하여 작성 해 BASE64 인코딩
하여 두번째 요소로 위치한다.
-암호화된 것이 아니기 때문에 개인정보를 담아서는 안된다.
ex) { “user-id” : 1, “exp”: 1539517391 }
서명
-JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분이다.
(계약서의 위변조를 막기 위해 사인하는 것과 같다.)
-BASE64 인코딩
된 헤더, 내용, JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화
하여 전송한다.
-프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화
하여 서버에서 생성한 JWT가 맞는지 확인한다.
1.Authentication 절차를 통해 유저 정보를 확인할 수 있는 access token
을 생성한다.(ex) user id)
2.유저가 request를 보낼때 access token
을 첨부해서 보낸다.
3.서버에서는 유저가 보낸 access token
을 복호화
한다.
4.복호화된 데이터를 통해 user id
를 얻는다.
5.user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인
하다.
6.유저가 권한을 가지고 있으면 해당 요청을 처리한다.
유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.