인증 백엔드 통합

REST API 인증 기법

Basic 인증

HTTP 요청에 아이디와 비밀번호를 보냄 --> 가장 간단한 인증.
헤더의 Authorization 부분에 아이디와 비밀번호를 콜론으로 이어붙인 후 Bas64로 인코딩한 문자열을 함께 보냄.

서버는 디코딩해 데이터베이스 또는 인증 서버의 레코드와 비교후 일치하면 수행, 일치하지 않으면 거부.

디코더만 있으면 누구나 알 수 있어 HTTP에 취약. 따라서 반드시 HTTPS와 같이 수행.
모든 요청이 로그인이기 때문에 로그아웃시킬 수 없다.

규모(scale)가 클 경우, 인증 서버와 인증 DB에 과부하가 걸릴 확률이 높다.

또,
인증 서버가 단일 장애점(전체 시스템을 가동불가하게 만드는 시스템의 한 부분)이 된다는 점.
위 그림과 같이 한 애플리케이션에 두가지의 서비스가 있을경우 서비스 1에서 인증하고 서비스 2로 넘어갈때 또 서비스 2에서 인증해야함. 즉 한 요청을 처리하는데 인증을 두번하게 됨.

토큰 기반 인증

토큰 : 사용자를 구별할 수 있는 문자열.
최초 로그인 시 서버가 만들어줌.

위 형식과 같이 'Authorization : Bearer 토큰' 을 명시. 서버는 이 토큰을 가지고 어떤 형태로든 인증해야 함.

토큰은 서버가 마음대로 설정할 수 있으므로 사용자의 인가정보, 유효기간을 정해 관리할 수 있음.
디바이스마다 다른 토큰, 다른 유효기간, 임의의 로그아웃 가능.

하지만 Basic에서 마주한 스케일 문제는 해결 불가.

JSON 웹 토큰

전자 서명된 토큰 즉, JSON 웹 토큰(JST)을 이용해 스케일 문제를 해결.
JWT는 말 그대로 JSON 형태로 된 토큰.
{header}, {payload}, {signature}로 구성 됨.

각 파트의 필드가 뜻하는 것.
Header

• typ : Type. 토큰의 타입을 의미
• alg : Algorithm. 토큰의 서명을 발행하기 위해 사용된 해시 알고리즘의 종류.

Payload

• sub : subject. 토큰의 주인을 의미. 유일한 식별자여야함.
• iss : Issuer. 토큰을 발행한 주체를 의미.
• iat : issued at. 토큰이 발행된 날짜와 시간.
• exp : expiration. 토큰이 만료되는 시간을 의미.

Signature

• 토큰을 발행한 주체 Issuer가 발행한 서명. 토큰의 유효성 검사에 사용.

서버가 헤더와 페이로드를 생성한 후, 전자 서명을 한다.

더이상 인증서버가 단일 장애점이 아니게 됨.
토큰을 훔쳐가면 리소스에 접근할 수 있으므로 HTTPS로 통신해야 함.

User 레이어 구현

저장할 정보가 Todo가 아닌 User일 뿐, 스프링 시큐리티와 큰 관련없이 독립적으로 사용할 수 있는 클래스이지만, 스프링 시큐리티와 접목해 사용할 수 있다.

UserEntity.java

UserRepository.java

UserEntity를 사용하기 위함.

UserService.java

유저 데이터베이스에 저장된 유저를 가져올 때 사용.

UserController.java

현재 유저를 가져오는 기능과 회원가입 기능을 구현.

포스트맨으로 테스팅
회원가입

로그인

구현 시 문제점.

• 로그인 후 로그인 상태가 유지가 안됨, 상태가 없으므로 상태를 기억하지 않기 때문.
• 유저의 로그인 여부 자체를 확인하지 않음 --> 임의로 유저아이디를 정해줬기 때문에 누가 로그인 했든 같은 Todo list가 보임
• 패스워드를 암호화 하지 않음.