안녕하세요 항상 웃음이 나는 픠식팀입니다 :)
SSO
Single Sign-On(SSO)는 1회 사용자 인증으로 다수의 애플리케이션 및 웹 사이트에 대한 사용자 로그인을 허용하는 인증 솔루션입니다.
SSO는 한 번 자격 증명이 검증된 사용자에게는 반복되는 로그인 없이 모든 암호 보호 리소스에 액세스 하도록 하여 보안과 사용자 경험을 모두 충족할 수 있다.
SSO의 구축 유형
- 인증 대행 모델(Delegation)
- 인증 방식을 변경하기 어려울 경우, 많이 사용
- 시스템 접근 시, 통합 Agent가 인증 작업을 대행
2. 인증 정보 전달 모델
- 웹 기반의 시스템에서 주로 사용
- 미리 인증된 토큰(Cookie 기능 이용)을 받아서 각 시스템 접근 시, 자동으로 전달한다.
쿠키를 이용한 SSO 구현시 보안 주의사항
- 데이터 기밀 유지(Data Confidentiality) : 토큰은 주요 암호 알고리즘과 128bit 이상의 키로 암호화 되어야 한다.
- 데이터 무결성(Data Integrity) : 토큰은 MAC 등을 포함해 데이터의 무결성을 보장 해야 한다.
- 사용자 주소 제한이나 유효 시간 제한 같은 보안 기술을 사용하여, 토큰을 네트워크에 노출 시키지 않아야 한다.
OAuth 2.0
OAuth가 탄생하게 된 이유는 위임 권한부여(Delegated Authorization) 때문이다.
위임 권한부여(Delegated Authorization)
위임 권한부여는 서드파티 어플리케이션이 사용자의 데이터에 접근하도록 허락해주는 것이다.
위임 권한부여에는 두 가지 접근 방법이 있다.
- 서드파티 어플리케이션에 아이디와 비밀번호를 주어서 사용자 대신에 사용자의 계정에 로그인하거나 사용자의 데이터에 접근하게 할 수 있다.
- OAuth를 이용해 서드파티 어플리케이션에 사용자 데이터에 대한 접근 권한을 줄 수도 있다.
OAuth란?
OAuth(Open Authorization)은 위임 권한부여를 위한 표준 프로토콜이다.
OAuth는 어플리케이션이 사용자의 패스워드 없이 사용자의 데이터에 접근 가능하도록 허가 해준다.
용어
리소스 사용자(Resource Owner): 클라이언트 어플리케이션이 접근하길 원하는 데이터를 가지고 있는 사용자
클라이언트(Client): 사용자의 데이터에 접근하고 싶어하는 어플리케이션
권한부여 서버(Authoriaztion Server): 사용자로부터 권한을 부여받음으로써 클라이언트가 사용자의 데이터에 접근할 권한을 부여해주는 권한 부여서버이다.
리소스 서버(Resource Server): 클라이언트가 접근하길 원하는 데이터를 갖고 있는 시스템이다.
때때로 권한부여 서버와 리서스 서버가 같은 경우가 있다.
액세스 토큰(Access Token): 리소스 서버에서 사용자에 의해 부여된 데이터에 접근하기 위해서 클라이언트가 사용할 수 있는 유일한 키가 바로 이 액세스 토큰
OIDC(OpenID Connect)
OpenID Connect는 OAuth 2.0 프로토콜의 최상위 레이어와 동일한 레이어다. OpenID Connect는 OAuth 2.0을 확장하여 인증 방식을 표준화한다.
OAuth는 유저 인증을 곧바로 제공하지 않지만 권한 부여를 위한 엑세스 토큰을 제공한다. OpenID Connect는 권한부여 서버에 의해 작동하는 인증 시스템을 기반으로 클라이언트가 사용자를 판단할 수 있게 해준다. 권한부여 서버에 유저 로그인과 동의를 요청할 때, openid라는 스코프를 정의하면 OpenID Connect 사용이 가능하다. openid는 OpenID가 필요되는 권한부여 서버에 필수적인 스코프이다.
SAML
SAML 또는 Security Assertion Markup Language는 애플리케이션이 SSO 서비스와 인증 정보를 교환하는 데 사용하는 프로토콜 또는 규칙 집합입니다. SAML은 브라우저 친화적인 마크업 언어인 XML을 사용하여 사용자 식별 데이터를 교환합니다. SAML 기반 SSO 서비스는 애플리케이션이 사용자 보안 인증 정보를 시스템에 저장할 필요가 없으므로 더 나은 보안과 유연성을 제공합니다.
SP(Service Provider): 서비스 제공 주체
User: 서비스를 사용하는 사용자
IdP(Identity Provider): 인증서비스 주체
SAML은 SP가 웹 사이트여야만 한다. 브라우저를 통해서만 SP와 IdP가 인증정보를 주고 받는다.
서버간 통신 없이 클라이언트를 통해서 인증 데이터를 주고 받기 때문에, POST 바인딩을 통해 인증정보 + 리다이렉션을 처리한다.
POST 헤더를 사용하는게 아니라 HTML내에 스크립트를 심어서 리다이렉트를 시키기 때문에 클라이언트가 웹사이트여야 한다는 문제점이 있다.
ex) form을 이용해 POST 요청을 만들어 IDP에서 얻은 인증 정보를 SP에게 전달
이러한 단점들이 있다.
전체적으로 SSO, OAuth, OIDC 그리고 SAML에 대해서 한번 확인해 보았습니다
'IT KNOWLEDGE' 카테고리의 다른 글
[Youtube API] YouTube Data API로 동영상 ID 추출하기 (0) | 2023.08.17 |
---|---|
정렬 알고리즘 개념 (0) | 2023.08.14 |
정적 팩토리 메서드(Static Factory Method) (0) | 2023.08.04 |
[Youtube API] YouTube Data API v3 개요 (0) | 2023.08.03 |
Keycloak과 Grafana 연동 (0) | 2023.07.21 |
댓글