개요
이제는 애플리케이션의 표준 플랫폼으로 되어가는 웹. 그리고 그것을 이용하는 고객의 사용자 인증(Authentication)과 인가(Authorization)는 중요해졌습니다.
HTTP 웹은 특성상 Connectionless 와 Stateless 한 특성을 가지고 있기 때문에, 내가 누구인지 서버에 알려줘도, 다음번 요청 때 누가 요청하는지 알 수 없는 것이지요. 그렇기 때문에 예전서부터 관련한 해킹 보안 사고도 자주 일어나고 있고, 복잡해지는 IT 시스템에서 이것을 방어하고, 잘 구현하는 것은 중요하고 어려운 사안이 되고 있습니다.
문제 인식 및 필요성
😢이제는 떠나보내자. 애증의 쿠키(Cookie)와 세션(Session)
우리는 http의 이 특성을 타파하기 위해 예전서부터 주로 클라이언트 side에서는 Cookie 인증 방식을, 서버 side에서는 Session 인증 방식을 구현해 왔지만, 그것들은 문제가 많습니다.
Cookie 인증 방식은 클라이언트 쪽에서 인증이다 보니깐, 얼마든지 위변조가 가능하고,
서버 쪽에서 인증 방식인 Session 방식은 서버가 부하된 트래픽을 Balanced 하기 위해 이중화 이상으로 구성한 환경에서는 무용지물이 됩니다. 게다가, 스티키 세션 또한 효율적이지 않습니다.
또한 애플리케이션 업데이트를 한 후 배포에 따른 서버 재기동으로 인해서 서버의 세션 정보는 초기화 되기 일쑤입니다.
그래서 우리는 더 나은 방법과 효율적인 인증 프로세스 기술 방식을 찾아야 합니다.
목표
🔐강한 보안 표준 인증 방식을 쉽게 통합
보안이 중요한 대외고객 서비스 웹/앱에 사용자 인증 방식을 쉽고 빠르게 추가 또는 변경함으로써 도입 비용을 줄이고, 오류를 줄이며, 보안을 높일 수 있어야 합니다.
또한, 고객사 API Data에는 고객 개인 정보 또는 보호되어야 할 정보들이 있을 수 있으므로, 기존 애플리케이션 데이터를 암호화, 은닉화, 캡슐화 그리고 데이터 압축 및 위변조방지를 하여 데이터의 신뢰도를 높이고, 안전하게 보호 할 수 있어야 합니다.
게다가, 기존 애플리케이션에 영향을 최소한으로 해야 하여 최소한의 작업으로 통합이 되어야 합니다.
❌️쿠키, 세션 인증 방식에 의존적이지 않음
사용자 인증 인가 정보 처리를, 보안에 좋지 않고 비효율적인 쿠키와 세션 방식에 의존적이지 않으면서, 구현이 쉬운 방식으로 인증 로직을 구현할 수 있어야 합니다.
또한 고객사 각각의 IT 시스템 환경에 맞게 구성하여 효율적으로 운용이 가능할 수 있어야 합니다.
솔루션
클라이언트 side의 인증 방식은 Revoke가 가능하게 구현된 JWT 인증 방식을 애플리케이션의 Filter Chain Layer에 삽입함으로써 효율성을 높이면서, 기존의 애플리케이션의 영향을 최소한으로 하였습니다.
또한, 서버 side 인증 방식은 In-memory 타입의 store를 따로 설치 하여, 애플리케이션에서 라이브러리 추가 하여 쉽게 이용하도록 구현하였습니다.
그 외에 고객사 각각의 IT시스템 환경과 니즈에 맞게 구성이 가능하고, SNS를 통한 oAuth2 인증, 프로젝트 컨설팅, 개발 및 수정이 가능하기 때문에 여러 환경에서도 통합이 가능합니다.
데모 화면
진행 프로세스
- 문의
- 담당 영업사원 배정 및 상담
- 계약
- 고객사 니즈 및 시스템 환경 파악을 위한 설문 조사 작성
- 프로젝트 진행
- 개발 및 배포
- 유지 보수