(항상 잘못된 정보가 포함되어 있을수 있습니다)
(잘못된 정보가 있다면 댓글로 피드백 부탁드리겠습니다)

인증

사용자가 제시한 신원이 실제로 그 시스템에 속한 것인지를 확인하는 과정
시스템이 가진 자원, 및 서비스의 안전성, 보안성을 유지하기 위해 무단 접근을 방지하고 신뢰성 있는 사용자만이 자원에 접근할수 있도록 하기 위해 사용

예시

• 네이버에서 회원 로그인을 하는경우
  로그인이라는 과정을 통해 사용자는 네이버라는 시스템 안에 속한 사용자 인지 확인
• 정부 사이트에서 등본을 발급받기 위해 휴대폰인증을 하는경우
  휴대폰인증이라는 과정을 통해 사용자가 대한민국 정부라는 시스템 안에 속한 사용자 인지 확인

인가

인증된 사용자가 시스템의 특정 리소스 혹은 기능에 대한 접근 권한을 가지고 확인하는 과정

예시

• 네이버 카페에서 특정 카페 글은 해당 카페에 가입해야지만 접근 할수 있는 경우
  특정 카페글의 리소스에 접근할수 있게 해당 카페 가입이라는 과정이 필요한것
• 은행앱에서 특정 금액 이상을 보내는경우 추가적으로 ARS 전화를 받아야하는 경우
  특정 금액 이상을 보낸다는 기능을 사용할수 있게 ARS 전화라는 과정이 필요한것

HTTP 인증

이전에 HTTP 관련 포스팅에서 HTTP는 Stateless 하다 했다.
복습하자면

HTTP 통신중 이전에 수행된 요청과 응답에 대한 정보를 저장하거나 유지 하지 않는다
각각의 요청과 응답은 모두 필요한 정보를 재각각 가지고 있어야 한다.

그렇다면 이런 Stateless하다는 특성때문에 인증을 하더라도
HTTP 통신을 할때마다 인증 과정을 거쳐야 할것이다.

매번 해당 서비스 혹은 기능에 접속할때마다 로그인을 해야하는 것이다.
그래서 나온 인증 상태를 유지하는 해결책들을 한번 알아보자

쿠키(Cookie)

클라이언트를 중점으로 인증 상태를 유지하는 방법

과정

• 클라이언트에서 서버에 로그인 요청을 한다
• 데이터베이스와 비교해 인증된 사용자라는게 식별되면 서버가 로그인 정보를 담은 쿠키를 생성해서 헤더에 담아 클라이언트로 전송한다.
• 클라이언트는 이 쿠키를 저장, 이후로 서버로 요청을 할때마다 쿠키를 담아 보낸다.
• 서버는 로그인정보를 담은 쿠키를 받아 데이터베이스와 비교해 인증된 사용자라는것을 식별한다.

장점

• 기존 로그인 정보를 사용하기 때문에 인증을 위한 추가적인 데이터 저장이 필요 없다.

단점

• 사용자의 주요 정보를 매번 요청에 담기 때문에 보안상 문제가 있다.
• 이렇게 쿠키를 전달하는 과정에서 쿠키가 노출되어 중간에 탈취할수 있다는 취약점이 있다는 것이다.

이런 단점들때문에 쿠키를 로그인과 같은 보안적으로 관련되 있는 기능에 쓰진 않고
장바구니 같은 기능이나, 오늘 다시보지않음 체크박스 와 같은 부분에 사용한다.

세션(Session)

서버를 중점으로 인증 상태를 유지하는 방법

과정

• 클라이언트에서 서버에 로그인 요청을 한다

• 데이터베이스와 비교해 인증된 사용자라는게 식별되면 서버가 클라이언트별 유일한 세션ID를 생성한후 서버 세션 스토리지에 저장한뒤 클라이언트로 전송한다

  세션ID는 사용자 정보를 담고있지 않다. 단지 사용자를 식별하는 값

• 클라이언트는 받은 세션ID를 이용해서 세션쿠키를 생성 및 저장, 이후로 서버로 요청을 할때마다 세션 쿠키를 담아 보낸다.

• 서버는 이런 세션쿠키를 받아 세션 스토리지에 저장해둔 세션ID와 비교후 인증된 사용라는것을 식별한다.

장점

• 쿠기 방식에 비해 성능적으로나 보안적으로나 우수하다.
• 쿠키와 다르게 사용자 정보를 직접 주고 받지않기때문에 상대적으로 안전하다

단점

• 사용자를 식별하는 세션ID를 생성하고 저장해야한다는 추가적인 작업이 생김
• 서버가 만약 여러개라면 여러서버에서 많은 조회가 생길시 세션 스토리지에 엄청난 부하가 생김

보안적으로 우수하다는 장점 때문에 로그인과 같은 보안적으로 중요한 기능에 사용한다.
반대로 서버의 자원을 사용하므로 부하를 방지하기 위해서 굳이 보안적으로 중요한 기능이 아니라면 상대적으로 편한 쿠키 방식을 사용한다.

토큰 (JWT)

클라이언트 중점, 서버중점으로 모두 인증 상태를 유지 했지만.
단점이 명확해서 생긴 이러한 단점을 해결하고 싶어서 나온 방법으로
HTTP 요청과 응답을 중점으로 토큰을 사용하는 방법.

과정

• 클라이언트에서 서버에 로그인 요청을 한다

• 데이터베이스와 비교해 인증된 사용자라는게 식별되면 서버는 가지고 있는 시크릿키을 이용해 사용자 정보를 암호화한 토큰을 만들고 별도의 스토리지가 아니라 서버 저장소에 저장한다
  그리고 이 액세스 토큰을 클라이언트로 전송한다.

  시크릿키 = 토큰을 생성하고 암호화 할때 쓰는 암호화키

• 클라이언트는 받은 액세스 토큰을 저장, 이후로 서버로 요청을 할때마다 액세스 토큰을 담아 보낸다.

• 서버는 받은 액세스 토큰을 가지고 있는 시크릿키로 유효성 검증을 진행해 인증된 사용자라는 것을 식별한다.

장점

• 세션 방식과 다르게 세션 스토리지를 따로 두지 않고 각각의 서버에서 검증을 할수 있다.
• 현대의 서버 시스템이 확장성을 중요하게 생각하는데 이는 서버가 1대였다가 3대가 되어도 동일 하게 진행할수 있게 할수 있다.

단점

• 액세스 토큰을 탈취하면 사용자와 똑같은 접근권한을 가지게 된다. 때문에 토큰이 탈취당하면 대처하기가 어렵다.

이러한 보안적인 문제때문에 이를 막기위해 액세스 토큰의 유효기간을 정해두게된다.
중요한건 이 유효기간이 지나면 탈취한 해커도, 사용자도 사용할수 없게 된다.
그래서 나온 개념이 Refresh토큰의 개념이다.

과정

• 서버가 시크릿키를 통해 토큰을 만들어 내는 과정까지는 똑같다
• 대신 서버가 액세스 토큰과 함께 리프레쉬 토큰도 만들고 이 리프레쉬 토큰만 따로 스토리지에 저장하고 클라이언트에게 이 두개의 토큰을 모두 전송한다.
• 클라이언트는 이 두개의 토큰을 모두 저장
• 후 과정은 모두 동일
• 서버는 액세스 토큰이 만료됐을때 요청이 오면 클라이언트에게 만료되었다고 알림
• 클라이언트는 액세스토큰과 리프레쉬토큰을 모두 서버로 전송
• 서버는 리프레쉬 토큰을 검증후 유효하다면 새로 갱신한 액세스 토큰을 발급후 전송
• 이 과정을 반복

이런 과정을 통해 액세스토큰만 사용하던 방식에 비해 보안을 조금이라도 더 안전하게 한것이다.