[ Concept ] SSO(Single Sign-On) 통합 인증 알아가기

[ Concept ]

[ Concept ] SSO(Single Sign-On) 통합 인증 알아가기

환이s 2024. 7. 11. 14:28

728x90

Intro

안녕하세요. 이 전 프로젝트를 마치고 안정화 기간을 가지면서 SM 담당자분께 인수인계 하다 보니 정신없는 하루를 보냈네요.

오늘은 CS 용어 중에서 접하게 된 SSO(Single Sign-On) 통신에 대해 정리해보겠습니다.

SSO(Single Sign-On)란?

SSO(Single Sign-On) 통신은 사용자가 한 번의 인증 절차를 거쳐 여러 시스템이나

애플리케이션에 접근할 수 있도록 해주는 기술입니다.

일반적으로 서로 다른 시스템 및 사이트에서 각각의 사용자 정보를 관리하게 되는데,

필요에 따라서 사용자 정보를 연동하여 사용해야 하는 경우도 생기게 됩니다.

이때, 하나의 사용자 정보를 기반으로 여러 시스템을 하나의 통합 인증을 사용하게 하는 것을 말합니다.

즉, 하나의 시스템에서 인증을 할 경우 타 시스템에서는 인증 정보가 있는지 확인하고 있으면 로그인 처리를 해주고 반대로 인증 정보가 없으면 다시 통합 인증을 할 수 있도록 만드는 것을 의미합니다.

생각해 보면 이 전에 Naver, Kakao 소셜 로그인 구현 했을 때, OAuth2.0 통신 방법도 SSO 관련 기술 중 하나입니다.

(Spring Security 파트 쪽에 상세하게 포스팅되어 있습니다.)

정리해 보자면, SSO 통신은 하나의 아이디 및 패스워드를 통해 여러 시스템에 접근할 수 있는 통합 로그인(인증) 솔루션이라고 알아두시면 좋을 거 같습니다.

SSO(Single Sign-On) - 구축유형

SSO는 크게 두 가지 유형인 인증 위임 모델(Delegation)과 인증 정보 전달 모델(Propagation)로 나뉩니다.

인증 위임 모델(Delegation)

권한을 얻으려는 서비스의 인증 방식을 변경하기 어려운 경우 사용합니다.
대상 서비스의 인증 방식 자체를 변경하지 않고, SSO Agent가 사용자 인증 정보를 관리하며 대신 로그인해 주는 방식입니다.
만약 Target Service에 로그인하기 위한 정보가 admin/passwd라면, Agent가 해당 정보를 가지고 있고, 로그인할 때 유저대신 Target Service에 사용자 정보를 전달해 로그인합니다.

인증 정보 전달 모델(Propagation)

웹 기반의 시스템에 주로 사용합니다.
통합 인증을 수행하는 곳에서 인증을 받아 '인증 토큰'을 발급받습니다.
유저가 서비스에 접근할 때 발급받은 토큰을 서비스에 같이 전달하게 되고, 서비스는 토큰 정보를 통해 사용자를 인식할 수 있습니다.

물론 웹 환경이라고 하더라도, Propagation 방식이 모두 적용될 수는 없습니다. 특히, 웹 애플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우에는 Delegation 방식을 사용해야 합니다.

또 하나 예시로, 대상 애플리케이션들이 많이 있고, 애플리케이션의 특성들이 다양한 경우에는 각 애플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO를 구성하는 방식도 있습니다.

SSO(Single Sign-On) - 서버 종류

SSO 시스템을 구현하는 방법 중에는 에이전트형(Agent-Based)과 서비스 프록시형(Service Proxy-Based) 접근 방식이 있습니다.

두 가지 접근 방식 모두 장단점이 있으며, 각각의 특성과 사용 사례에 대해 알아보겠습니다.

에이전트형 SSO(Agent-Based SSO)
- 에이전트형 SSO는 각 애플리케이션 서버에 SSO 에이전트를 설치해서 작동시키고, 애플리케이션 서버와 SSO 서버 간의 통신을 관리하고 사용자를 인증합니다

[ 특징 ]

통합 방식 : 각 애플리케이션 서버에 직접 SSO 에이전트를 설치.
인증 관리 : 애플리케이션 서버와 SSO 서버 간의 인증 요청과 응답을 관리
애플리케이션 변경 : 기존 애플리케이션의 코드 변경이 거의 필요 없으나, 서버 구성 변경 필요.

[ 장점 ]

보안성 : 에이전트가 직접 애플리케이션 서버에 설치되어 있어, 보다 강력한 보안 제어 가능하다.
세밀한 제어 : 각 애플리케이션 서버에 대해 세밀한 인증 및 권한 제어가 가능하다.
독립성 : 애플리케이션에 대한 의존도가 낮아 다양한 환경에서 사용 가능하다.

[ 단점 ]

복잡성 : 각 서버에 에이전트를 설치하고 관리해야 하므로 초기 설정 및 유지보수가 복잡할 수 있다.
확장성 : 많은 서버에 에이전트를 설치해야 할 경우, 관리가 어려워질 수 있다.

[ 예시 코드 ]

Java 웹 애플리케이션의 SSO 필터
public class SSOAgentFilter implements Filter {
    private SSOAgent ssoAgent;

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        ssoAgent = new SSOAgent();
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
            throws IOException, ServletException {
        if (!ssoAgent.isAuthenticated((HttpServletRequest) request)) {
            ssoAgent.redirectToLogin((HttpServletResponse) response);
        } else {
            chain.doFilter(request, response);
        }
    }

    @Override
    public void destroy() {
    }
}

서비스 프록시형 SSO(Service Proxy-Based SSO)
- 서비스 프록시형 SSO는 중앙 집중형 프록시 서버를 통해 SSO 기능을 제공하고, 모든 인증 요청은 프록시 서버를 통해서 처리되며, 애플리케이션 서버는 인증에 대한 부담을 덜 수 있습니다.

[ 특징 ]

통합 방식 : 중앙의 프록시 서버를 통해 모든 인증 요청 처리한다.
인증 관리 : 프록시 서버가 사용자 인증을 수행하고, 인증 토큰을 발급한다.
애플리케이션 변경 : 애플리케이션 서버의 변경이 거의 필요 없다.

[ 장점 ]

중앙 집중 관리 : 인증 요청을 중앙에서 관리할 수 있어, 관리가 용이하다.
유연성 : 다양한 애플리케이션과의 통합이 쉽다.
확장성 : 프록시 서버를 통해 다양한 애플리케이션에 쉽게 SSO 적용 가능하다.

[ 단점 ]

단일 장애점 : 프록시 서버가 다운되면 모든 애플리케이션에 영향이 미친다.
성능 병목 : 모든 인증 요청이 프록시 서버를 거치므로, 대규모 트래픽에서 성능 저하 가능성이 있다.

[ 예시 코드 ]

#NGINX 프록시 서버를 이용한 SSO 설정
http {
    server {
        listen 80;
        
        location / {
            proxy_pass http://backend_server;
            auth_request /auth;
        }

        location = /auth {
            proxy_pass http://sso_server/authenticate;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            proxy_set_header X-Original-URI $request_uri;
        }
    }
}

[ 정리 ]

에이전트형 SSO : 높은 보안성과 세밀한 제어가 필요한 환경에 적합하지만, 초기 설정 및 유지보수가 복잡할 수 있습니다.
서비스 프록시형 SSO : 중앙 집중 관리가 용이하고 다양한 애플리케이션과의 통합이 쉬우나, 단일 장애점과 성능 병목에 주의해야 합니다.

따라서 각 접근 방식의 특성을 이해하고, 조직의 요구사항에 맞는 솔루션을 선택하는 것이 중요합니다.

SSO(Single Sign-On) - OAuth 2.0을 이용한 Token-based SSO

마지막으로 토큰 기반 SSO에 대해 알아보겠습니다.

토큰 기반 SSO는 JWT(JSON Web Token)와 같은 토큰을 사용하여 인증을 처리하는 방식입니다.

사용자가 인증되면 IdP는 토큰을 발급하고, 사용자는 이를 통해 SPs를 거치고 다른 서비스에 접근합니다.

[ IDP(Identity Provider) ]

IDP는 사용자의 신원을 인증하고 그 정보를 서비스 제공자에게 전달하는 역할을 합니다.
또한, 사용자 로그인 정보를 저장하고, 사용자가 인증할 수 있도록 로그인 페이지를 제공합니다.

1. 주요 기능

- 사용자 인증 : IDP는 사용자 이름과 비밀번호, 또는 다른 인증 방식을 통해 사용자를 인증
- 토큰 발급 : 인증이 성공하면 IDP는 인증된 사용자에 대한 정보를 포함하는 토큰을 발급
- 통합 인증 관리 : IDP는 여러 애플리케이션에 대해 중앙에서 인증을 관리

[ SP(Service Provider) ]

SP는 실제로 사용자에게 서비스를 제공하는 애플리케이션이나 시스템입니다.
SP는 사용자가 액세스 하려고 할 때 IDP를 통해 인증을 요청하고, IDP로부터 받은 인증 정보를 사용하여 사용자를 신뢰합니다.

1. 주요 기능

- 인증 요청 : SP는 사용자가 서비스에 접근하려 할 때 IDP에 인증을 요청
- 토큰 처리 : SP는 IDP로부터 받은 인증 토큰을 검증하고, 토큰에 포함된 사용자 정보를 사용하여 사용자를 식별
- 서비스 제공 : SP는 인증된 사용자에게 서비스를 제공

[ IDP와 SP의 상호작용 ]

1. 사용자 요청: 사용자가 SP에 접근하려고 시도합니다.
2. 리디렉션: SP는 사용자를 IDP로 리디렉션하여 인증을 요청합니다.
3. 사용자 인증: 사용자는 IDP에서 인증을 수행합니다 (예: 사용자 이름과 비밀번호 입력).
4. 토큰 발급: IDP는 인증이 성공하면 사용자에 대한 정보를 포함하는 인증 토큰을 발급합니다.
5. 토큰 전달: IDP는 이 토큰을 SP로 전달합니다.
6. 토큰 검증: SP는 받은 토큰을 검증하고, 토큰에 포함된 사용자 정보를 사용하여 사용자를 신뢰합니다.
7. 서비스 제공: SP는 인증된 사용자에게 접근을 허용하고 서비스를 제공합니다

토큰 기반 SSO는 토큰을 통해 분산된 시스템에서도 효율적으로 인증을 처리할 수 있는 확장성을 갖고 있고, 암호화를 적용하여 보안성을 강화할 수 있습니다.

하지만 주의 사항으로는 토큰의 유효 기간과 갱신 정책을 관리해야 하고, 만약 토큰이 탈취되면 다른 서비스에 접근할 수 있는 위험이 있습니다.

예제를 통해서 알아보겠습니다.

[ OAuth 2.0을 이용한 Token-based SSO ]

1. 사용자 인증 요청

사용자가 클라이언트 애플리케이션에 접근하여 인증을 요청합니다.

GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=openid%20profile&state=STATE HTTP/1.1
Host: authorization-server.com

2. 사용자가 IdP에서 인증

사용자가 IdP 로그인 페이지에서 인증을 수행합니다.

3. Authorization Code 발급

인증 후 IdP는 Authorization Code를 클라이언트 애플리케이션에 리디렉션합니다.

HTTP/1.1 302 Found
Location: REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. 토큰 요청

클라이언트 애플리케이션은 Authorization Code를 사용하여 액세스 토큰을 요청합니다.

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

5. 토큰 발급

IdP는 액세스 토큰과 ID 토큰을 클라이언트 애플리케이션에 반환합니다.

{
  "access_token": "ACCESS_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "ID_TOKEN"
}

6. 서비스 접근

클라이언트 애플리케이션은 액세스 토큰을 사용하여 서비스에 접근합니다.

GET /resource HTTP/1.1
Host: resource-server.com
Authorization: Bearer ACCESS_TOKEN

이러한 과정을 통해 사용자는 한 번의 인증으로 여러 서비스에 접근할 수 있고, 토큰 기반 인증을 통해 효율적이고 확장 가능한 SSO 환경을 구축할 수 있습니다.

마치며

프로젝트 진행하면서 SSO라는 용어를 접하게 돼서 포스팅을 해보았습니다.

개발만 하다가 CS 용어를 접하게 되면 생소하지만 알아가야 한다는 생각을 하다 보니 포스팅을 통해서 의미 있는 정리 시간이었던 거 같습니다.

다음 포스팅에서 뵙겠습니다.

728x90

저작자표시

'[ Concept ]' 카테고리의 다른 글

[ Concept ] 프로젝트 산출물 - 화면설계서 (3)	2024.12.04
[ Concept ] HTTP와 HTTPS의 차이점 (0)	2024.08.20
[ Concept ] 분산 코디네이터 Zookeeper(주키퍼) 알아가기 (0)	2024.05.20
[ Concept ] 대용량 / 실시간 데이터 처리를 위한 오픈 소스 (Apache Kafka) (0)	2024.05.17
[ Concept ] SOAP 와 REST API의 장단점 및 비교 (0)	2023.07.20

현재글[ Concept ] SSO(Single Sign-On) 통합 인증 알아가기

환이의 개발일지