OAuth2 로그인이라고 하면 카카오, 구글, 네이버 등의 인증정보를 바탕으로한 로그인이 떠오른다. 믿을 수 있는 외부사이트에서의 인증정보를 바탕으로 현재 서비스를 이용할 수 있는 권한을 얻는 것이다.
이는 서비스의 개수가 많아지더라도 일관된 하나의 방법으로의 로그인을 지원한다는 점에서 장점이 있다. A, B, C ... 서비스가 많아지더라도 인증방식을 지원하기만 한다면 매번 새롭게 로그인을 진행하지않고도 서비스의 이용이 가능해진다.
이러한 인증 솔루션을 SSO(Single Sign On, 통합 인증) 이라고 부른다.
그러나, 쉽게 접하는 인증 프로토콜이 OAuth2라서 그런걸까? 나도모르게 OAuth2 == 통합인증 이라고 생각하게되는 경향이 있는 것 같다.
그래서 이번 포스팅에서는 SSO와 관련 프로토콜의 종류 등에 대해서 알아볼 생각이다.
SSO(Single Sign On)
SSO는 단일 인증, 통합 인증 등으로 불리며 하나의 인증수단을 이용해 다양한 서비스의 이용권한을 얻는 솔루션을 뜻한다. 예를들어, 네이버 사용자는 한번의 로그인으로 메일, 페이, 카페, 블로그 등 다수의 서비스를 사용할 수 있다.
SSO는 서비스 공급자(SP)와 ID 공급자(IdP) 또는 SSO 솔루션간의 디지털 신뢰를 기반으로 동작한다.
IdP(Identity Provider)
소셜 IdP(Google, Facebook 등), 엔터프라이즈 IdP(ADFS, Okta 등), 클라우드 기반 IdP(Okta, AWS Cognito 등) 등의 유형이 존재한다.
소셜 IdP의 경우, 일반적으로 OAuth2와 OIDC 프로토콜을 사용하며, 엔터프라이즈 IdP는 주로 LDAP이나 SAML 프로토콜을 사용한다.
일반적인 SSO 인증의 동작흐름은 아래와 같다.
- 사용자가 서비스 제공업체 등에 SSO 자격증명을 사용한 로그인 시도
- 인증에 성공한 경우, 사용자 ID에 대한 특정정보(이름, 이메일 등)가 포함된 세션 인증 토큰을 생성하고, 사용자의 웹 브라우저 혹은 SSO 시스템에 저장
- 다른 서비스 제공업체에서 접근하려하면 인증여부 확인
- 이미 인증을 받은 경우 디지털 인증서로 서명된 인증토큰을 반환, 서비스 제공업체에서는 토큰 검증 및 접근권한 부여
4-1. 그렇지 않은경우, 사용자에게 자격증명 재입력 요구
위 동작흐름은 단순 SSO에 대한 동작흐름을 나타낸다.
단일 로그인 및 자격 증명 집합으로 여러개의 관련 애플리케이션에 대한 세션 접근을 제공한다.
단순 SSO 외에도 SSO 파생들이 여럿 존재한다.
- 적응형 SSO
- 사용자가 새로운 장치에서의 로그인 혹은 특히 민감한 정보에 접근하려고 할때 추가인증요소나 새 로그인을 요구한다.
- 페더레이션 ID 관리(FIM)
- SSO가 단일 조직내의 애플리케이션간 신뢰관계를 기반으로 동작한다면, FIM은 이를 외부의 신뢰할 수 있는 공급업체 및 기타 서비스 제공업체로 확장한다. 예를들어, 조직 내에서 로그인한 사용자가 추가 로그인없이 이름등을 이용한 간단한 로그인을 통해 타사 웹 애플리케이션에 접근할 수 있다.
- 소셜로그인
- 구글, 네이버, 카카오 등 인기있는 소셜 미디어 사이트의 자격증명과 동일한 자격증명을 사용한 애플리케이션 인증을 지원한다.
OAuth 2.0(Open Authorization 2.0)와 OIDC(Open ID Connect)
OAuth2는 Spring Security를 공부하면서 관련된 글을 작성했던 경험이 있다.
OAuth2 Login와 OAuth2 Client를 작성하면서 OAuth2 동작방식과 Spring Security에서의 지원내용을 정리했던 기억이 있다.
OAtuh 2.0은 트위터와 구글이 정의한 개방형 인가(Authorization) 표준을 의미하며,
OIDC는 OpenID Foundation에서 정의한 개방형 인증(Authentication) 표준을 의미하며, OAuth 2.0 프레임워크를 기반으로 한다.
OAuth 2.0 동작흐름의 주요 구성요소는 4가지로, Client, Resource Server, Resource Owner, Authorization Server 가 존재한다.
OAuth 2.0의 동작흐름을 간략하게 설명하면 아래와 같다.
Client에서 Resource Owner에게 인가권한을 요구하고, 이를 인가서버로 전달한다.
만약, 이 인가권한이 유효하다면 인가서버에서 엑세스토큰이 반환되며, 최종적으로 이를통해 Resource Server에 접근할 수 있다.
OIDC는 OAuth 2.0의 확장이기 때문에 동일한 구성요소를 가지지만 용어에서 약간의 차이가 존재한다.
- OpenID Provider : OAuth 2.0의 Autorization Server를 의미한다.
- relying party : OAuth 2.0의 Client를 의미한다.
OIDC의 동작흐름은 OAuth 2.0과 거의 동일하게 동작하지만, 인가서버에서 반환되는 토큰에 ID 토큰이 추가된다.
Access 토큰이 자원에 대한 접근 권한을 나타낸다면, ID토큰은 JWT의 형태로 사용자에 대한 인증정보를 담고있다.
즉, OAuth 2.0은 외부 애플리케이션의 특정 자원에 접근할 수 있는 권한을 취득하는 과정을 의미한다.
사용자 신원을 확인하지 않기때문에 로그인 과정을 의미하지 않으며, 흔히 말하는 OAuth 2.0 로그인은 OIDC 로그인을 의미한다.
OIDC Authorization Code with PKCE 동작흐름
- Client에서 인가코드 탈취 방지를 위한 PKCE Code 생성
/authorize로 인가코드 요청 생성- 인가서버에서 사용자에게 인가권한을 위한 인증 요청
- 인증이 성공한 경우 인가코드를 Client로 반환
- Client에서 인가코드와 PKCE Code를 인가서버로 전달 (
/token)- PKCE Code를 확인하고, 인가서버에서 Client로 Access 및 ID 토큰 반환
- Access Token을 이용해 Resource Server에 자원 요청 및 응답
SAML(Security Assertion Markup Language)
명칭에서 확인할 수 있듯이 XML 기반 메시지를 이용하여 사용자 인증을 수행한다.
SAML 동작과정
- 사용자가 브라우저를 통해 서비스 제공자(SP)에 접근
- SP에 SAML 요청을 브라우저로 redirect
- 브라우저에서 SAML 요청을 IdP로 전달
- IdP에서 사용자 정보 인증 진행
- SAML Assertion을 생성하여 브라우저로 전달
- 브라우저에서 SAML Assertion을 SP로 전달
- 사용자가 인증된 경우, SP에서 브라우저로 인증정보 등을 전달
- 브라우저에서 SP로의 자원 요청
- SP에서 요청받은 자원 응답
IdP에서 생성하여 SP로 전달하는 SAML Assertion은 XML 형식을 띈다.
