일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 오블완
- MySQL
- kotlin
- 공부
- Java
- Elasticsearch
- Linux
- Kubernetes
- APM
- kotlin querydsl
- mysql 튜닝
- 정보처리기사실기 기출문제
- Spring
- 정보처리기사 실기 기출문제
- 정보처리기사 실기
- AI
- CloudWatch
- aws
- kotlin coroutine
- minikube
- CKA 기출문제
- 코틀린 코루틴의 정석
- AWS EKS
- IntelliJ
- 기록으로 실력을 쌓자
- 티스토리챌린지
- CKA
- Pinpoint
- PETERICA
- kotlin spring
- Today
- Total
피터의 개발이야기
SSO란 무엇인가? 본문
회사에서 구글 OAuth와 Apple OAuth를 위한 백엔드 개발을 하였습니다. 그러면서 예전에 개발하였던 SSO과 차이점을 경험하게 되었습니다. 제가 경험했던 SSO에 대해 되짚어보며 OAuth에 대해서 설명을 하도록 하겠습니다.
SSO란 무엇일까요?
Single Sign On의 약자로, 한번의 로그인으로 여러 어플리케이션을 사용하는 기술을 말한다. 각 어플리케이션의 로그인/인증부분을 한 군데로 통합하여 관리하는 방법이다. 혹은 인증된 토큰을 이용하여 다른 어플리케이션도 로그인처리를 해준다.
기억의 회상, SSO 사용했던 이유
기존에 이미 A서비스가 있었습니다. 그리고 A서비스를 기반으로 한 플러스 상품으로 2개의 어플리케이션이 추가가 되었습니다. 서비스 확장 시 기획단계에서 요구사항으로 SSO를 요구하였습니다. A서비스를 사용하는 고객이 자연스럽게 플러스 상품도 쉽게 사용할 수 있도록, 로그인을 간소화 하는 방법이 필요하였습니다.
SSO를 어떻게 구현할까?
서비스들의 사용자 정보는 DB link로 공유가 되었고, 사용자정보 업데이트는 한곳에서 이루어졌었습니다. 즉, StoreId정보는 동일하게 사용가능하였습니다.
1차 고민, 세션공유방법
처음 시도하였던 방법은 세션을 공유하는 것이었습니다. 세션 자체에 유니크키를 생성하고, 로그인 시 JAR형태로 배포된 세션공유 유틸을 이용하여 다른 시스템에 static map에 세션을 저장하는 방식이었습니다. 하지만 이것은 메모리상에 존재하기 때문에 시스템 반영이나 다른 이유의 장애 시에 세션처리가 곤란할 경우가 있었습니다.
2차 토큰방식
회사에서 ORACLE을 사용하기 있어서 USER정보는 디비링크를 이용하여 공유하고 있었습니다.
그래서 토큰 방식으로 인증된 USER정보를 바탕으로 로그인처리를 하고 세션을 생성하는 방식이었습니다.
토큰의 방식 형태는 다음과 같았습니다.
고유키값_StoreID_토큰시간제약
이 주어진 토큰을 이용해 인증을 확인하며, 혹여 인증이 탈취되어도 토큰의 시간제약을 통해 남용을 방지하였습니다. 주어진 토큰에서 StoreId를 추출하여 세션정보를 생성하여 로그인 처리를 하였습니다.
OAuth를 개발하면서 느꼈던 차이점
로그인정보는 한곳에서만 관리하는 것이 보안에 유리하다.
시대가 지나면서 웹을 통한 다양한 서비스가 생겨났다. ID, Password를 통한 로그인은 보안이 취약하였다. 사용자들은 많은 사이트의 아이디와 비밀번호를 따로따로 관리하기는 힘든 일이다보니 동일한 로그인 정보를 사용하였다. 이런 면에서 OAuth는 한 사이트에서만 인증을 거치면 다른 사이트엔 비밀번호를 저장할 필요가 없었다.
세션에서 인증토큰방식으로의 전환
SSO를 개발할 당시 서버 아키텍처는 3teir였고, 세션을 활용한 보안체크를 주로 사용하였다. 인증된 세션은 세션 클러스터링을 통해 다중서버로 공유하여 사용자의 정상적인 로그인 여부를 판단하였다. 당시 WAS가 많아도 4대정도였기 때문에 세션클러스터링이 가능하였지만, 마이크로서비스를 지향하는 백엔드 환경에서는 세션정보 자체가 무거웠고, 여러 단계를 거치면서 공유자체가 까다로웠다. 더욱이 통신 방식이 RESTful 지향하였으며, 비동기적 요청들이 점점 활성화 되었다. 토큰 자체를 통해 인증여부를 판단하고, 인증된 사용자의 고유식별 정보를 얻을 수 있었다.
OAuth(open standard for authorization)란?
구글이나 아이폰 로그인을 통해 인증된 정보를 통해 ID/Password를 노출하지 않고도 다른 웹서비스를 이용하는 방식을 말한다.
예를 들어 애플 사용자는 안전성이 보장되어있는 애플로그인을 통해 다른 웹서비스에 접속할 수 있도록 한다. 더욱이 새로운 사이트에는 회원가입 또는 개인정보를 따로 저장하지 않고 애플 로그인 하나만으로도 이용할 수 있다.
정리
SSO는 일종의 서비스였다. 하나의 사이트를 접속하였다면 다른 사이트도 쉽게 이용할 수 있도록 개발되었지만, 이는 범용적으로 사용할 수는 없었다. SSO의 한 개념이기는 하지만 OAuth는 일종의 인증 프로토콜이 되어 개인의 정보를 최소화하여 인증처리를 하는 것이다. 그래서 SSO 서비스는 OAuth방식을 사용하여 만들 수도 있는 것이다.
'개발이야기' 카테고리의 다른 글
Mac에서 port 프로세스 kill하기 (0) | 2021.02.06 |
---|---|
웹페이지 내에 PDF 웹 뷰어 만들기 (0) | 2021.01.21 |
[TDD] LocalStack이란 (0) | 2020.12.19 |
기록으로 실력을 쌓자 (0) | 2020.12.12 |
Java 개발자라면 꼭 보아야할 동영상 (0) | 2020.12.12 |