본문 바로가기

기타

SSO 종류

SSO 패턴(MODEL)

SSO의 패턴은 크게 두가지 패턴이 있다.

1. Delegation Model - 인증 대행

  ㄴ어플리케이션 인증 정보를 Agent(서비스 제공자)가 관리하여 사용자 대신 로그인 해주는 방법

  ㄴ중간 체계 Agent (서비스 제공자)를 통해야만 어플리케이션 로그인 가능

 

User -> Agent(로그인) -> Application(사용자 정보로 접근)

 

 

2. Propagation Model - 인증 정보 전달

  ㄴ서비스 제공자가 토큰을 제공하여 어플리케이션애 접근시 토큰을 통하여 사용자를 확인하는 방식

 

User -> Auth Service -> User(Token) -> Application(Token으로 접근)

 


SSO 종류

SSO종류는 대표적으로 SAML / OAuth / OIDC가 있다.

 

 

1. SAML

 

초기 SAML이 출현하기 이전, 기업들은 독자적인 인터페이스 또는 SSO 솔루션을 사용하여 구축하였는데,

SSO솔루션들은 Private망에서 인증정보를 Cookie에 담아 사용하는 방법을 사용하였지만,

Public망에서는 보안적으로 문제가 있었습니다.

*Public망에 인증 정보가 Cookie로 남기 때문에

 

SAML은 인증정보를 XML포맷(형식)으로 생성하여 해당 XML데이터를 암호화하여 최종 수신자에게 전달하도록 구현하였습니다.

*암호함으로 제 3자에게 노출되지 않도록

 

이때 생성된 XML을 Assertion이라고 부른다

*Assertion에는 ID, 공급자 이름, 발행일 및 만료일 등등의 정보가 담긴다.

 

SAML Request, Saml Response는 XML형식이라 브라우저를 통해서만 동작 가능하여 모바일이나 Native Application에는 부적절함

 


 

SAML유형

SAML에 포함되는 세가지 유형의 명령문이 있다.

    1. Authentication - 인증

       ㄴ사용자를 검증, 식별 후 로그인 시간과 사용한 인증의 유형(암호, 다단계 인증 등)을 포함한다.

 

     2. Attribute - 속성

       ㄴ SAML Token을 공급자에게 전달하고 사용자에 관한 특정 데이터를 포함한다.

  

 

     3. Authorization Decision - 권한 부여 결정

       ㄴ서비스 공급자에게 사용자가 인증되었는지 아니면 자격 증명에 문제가 있는지,

      해당 서비스를 사용할 권한이 없어서 액세스가 거부되었는지 알려준다.

 

 

 

SAML 인증 Flow

인증 Flow에는 3가지 역할이 있다.

User - 사용자

Identity Provider(IDP) - 인증 정보 제공자

Service Provider(SP) - 서비스 제공자

 

1. User -> SP

서비스 제공 요청

 

2. SP Access Check

SP에서 서비스 액세스 인증을 체크

*인증 되지 않은 User에 경우 3번

 

3. SP -> User

인증되지 않은 User이므로 인증요청을 클라이언트(Browser)에 전송

*SP에서 SAML Request를 생성하여 User(Browser)에게 전송

SP는 IDP와 직접 연결되지 않고 유저의 클라이언트(Browser)에서 IDP로 SAML Request를 Redirect한다.

 

4. User -> IDP

클라이언트(Browser)에서 SSO서비스 요청

IDP는 SAML Request를 파싱하여 User인증을 진행한다.

*인증 방식은 패스워드, PKI등 다양하게 사용할 수 있다.

 

5. IDP -> User

인증 성공하게 되면 SAML Response를 생성하여 User에게 전송

*SAML Response에는 SAML Assertion이 포함된다.(XML형식)

IDP는 브라우저에 Session, Cookie를 설정한다.

 

6. User -> SP

User는 SP의 ACS URL로 SAML Response를 POST 방식으로 전달한다.

*ACS(Assertion Consumer Service) - SAML 인증 성공시 제공되는 SAML Response를 받는 Callback URL

 

7. SP -> User

SAML Response를 검증하여 유효시 User가 요청한 서비스를 Forwarding함 - 로그인 성공처리

 

* Redirect : Forwarding

Redirect - 서버에서 클라이언트에게 요청한 URL이 아닌 또 다른 URL로 재접속을 명령하는 것

Forwarding - 서버 내부에서 다른 URL을 요청하여 해당 URL의 리소스를 응답하는 것

 

 

 

 

 



 

 

2. OAuth

OAuth란 Open Authorization의 약자로 개방향 표준 권한 프로토콜이다.

사용자의 동의를 받고 계정 정보에 접근할 수 있도록 권한을 주는 기능

 

많은 웹사이트에서 사용되고 있는데, Google, Facebook, Twitter, GitHub, Naver, Kakao등등에서 사용되고 있다.

서비스를 사용하고자 하는 사이트의 계정의 연동해둔 웹사이트의 계정으로 액세스 권한을 부여받아 서비스를 이용할 수 있게 한다.

 

 

OAuth의 장점

제각각의 계정 정보(아이디/비밀번호)를 기억하고 로그인할 필요 없이 서비스를 제공하는 플랫폼 계정으로 통합하여 이용할 수 있는 편리함

 

OAuth의 단점

1. CSRF(Cross-Site Request Forgery) 공격

  ㄴ피해자의 권한을 도용하여 웹 어플리케이션에 요청을 위조하는 공격으로,

      SNS 계정을 연동하여 사용하게 되는데, 이때 CSRF공격으로 피해자 계정에 공격자 계정을 연동

2. Convert Redirect

  ㄴ공격자는 변조된 Redirect URI를 보내 로그인을 유도, 로그인시 반환되는 Authrization Code를 통해 계정을 탈취

 

 

OAuth1.0 : OAuth 2.0

OAuth에도 버전이 있다.

비교 OAuth1.0 OAuth2.0
참여자 구분 User, Consumer, Service Provider Resource Owner, Client, Authorization Server, Resource Server
Token Request Token, Access Token Access Token, Refresh Token
Authentication 요청 된 Signature(서명) Security Token
Expired date 없음 Access Token 유효기간 부여, 만료 시 Refresh Token 이용
Client Web Service Web

 

OAuth1.0 -> OAuth2.0에서 달라진 점
1. 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.


2. HTTPS를 통해 암호화를 하여 과정의 단순화를 하였다.

  ㄴ HTTPS를 통해 데이터가 암호화되므로 토큰 교환 및 인증 프로세스가 중간에 가로채지거나 조작되는 것을 방지

  ㄴ기본적인 브라우저는 HTTPS를 지원하기 때문에 OAuth2.0의 구현이 단순화


3. 다양한 인증 방식이 제공된다.

  ㄴ Authorization Code Grant 권한 부여 승인 코드 방식

  ㄴ Implicit Grant 암묵적 승인 방식

  ㄴ Resource Owner Password Credentials Grant 자원 소유자 자격증명 승인 방식

  ㄴ Client Credentials Grant 라이언트 자격증명 승인 방식


4. API 서버에서 Authentication Server와 Resource Server가 분리됐다.

  ㄴ서비스 제공서버 즉 API서버에서 액세스 토큰 인증과 서비스 제공을 함께 하였다.

  ㄴOAuth2.0에서는 인증서버와 리소스서버가 분리되어 인증서버에서는 액세스 토큰을 발급하고

      리소스서버에서는 토큰 검증 및 서비스를 제공한다.

  ㄴ인증 서버는 인증에만 집중하고, 리소스 서버는 리소스에 대한 접근 제어 역할을 전담하여 보안을 강화

 

https://blog.naver.com/mds_datasecurity/222182943542

 

OAuth 2.0 동작 방식의 이해

OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜입니다. 이 프로토...

blog.naver.com

 

 

3. OIDC

OIDC(Open Identity Connection)

OAuth2.0 프로토콜을 기반으로 간편하게 인증을 처리하고 신원확인 서비스(IDP)를 통해 안전한 방식으로 사용자 정보를 제공 받는다.

*IDP는 OP(OpenId Provider)를 의미하며, 카카오, 네이버, 구글등등이 해당된다.

간편 회원가입으로 보면 될 것 같다.(사용자의 정보를 제공받아 간편하게 가입됨)

 

 

 

4.Onrrow

 

 


 

SAML과 OAuth와 OIDC

동일한 기능을 갖고 있지만 사용하는 기술과 프로세스는 다르다.

 

SAML - XML형식으로 데이터를 전달

           - IDP라는 해당 서비스에 사용자의 인증 및 자격 정보를 저장하여 사용

           - 사용자의 인증 / Authentication

 

OAuth - JWT(Json Web Token) 또는 JavaScript 개체 표기법을 사용하여 데이터를 전달

           - 서비스에 아이디와 패스워드를 사용하여 로그인하는 대신 Google, Naver, Kakao 등등의 IDP를 연동하여

             계정의 권한으로 로그인

           - 사용자의 인가 / Authorization

 

OIDC - JWT(Json web Token) 형식의 IdToken을 제공

           - 사용자의 인가 / Authorization

           - OAuth를 사용하여 사용자의 인증 및 사용자의 정보를 IdToken으로 제공,

             해당 IdToken으로 사용자정보를 추출하여 검증

 

'기타' 카테고리의 다른 글

Proxy  (0) 2024.04.25
OAuth의 Grant Type  (0) 2024.04.25
SSO 구현 기법  (0) 2024.04.25
WEB Server VS WAS  (0) 2024.04.24
RBAC VS ABAC  (0) 2024.04.24