1. 배경
- Spring Security 를 이용하다보니 로그인 방식을 구현할때
form loginSAML2OAuth방식이 있는 것을 확인 했다.
현재 formLogin 의 경우는 스프링 타임리프를 이용한 form 에서의 요청을 통해 로그인 되도록 구현하고 있다.
하지만 나머지 방식인 salm2 OAuth 의 경우는 따로 알아둘 필요가 있어서 정리해보고자 한다.
- 참고 : 두 가지 모두 웹 SSO(Single Sign On)에 사용되지만 SAML이 사용자를 위한 프로세스라면 OAuth는 애플리케이션을 위한 프로세스라고 할 수 있다.
2. SAML2
-
SAML(Security Assertion Markup Language)
-
일단
okta에서 말해주고 있는 SAML 의 정의는 아래와 같다.
SAML은 아이덴티티를 확인하고 인증을 제공하는 개방형 표준으로서, 일반적인 사무 환경에서 직원이 사내 직무에 액세스하려면 먼저 로그인을 해야 합니다.
SAML 인증이 완료되면 기업 인트라넷, Microsoft Office, 브라우저 등 모든 툴에 액세스할 수 있습니다. SAML을 통해 한 번의 디지털 서명으로 모든 리소스를 이용할 수 있는 것입니다.
보안이 특히 엄격한 기업이라면 SAML 인증을 통해서만 문을 열거나 컴퓨터 화면 잠금을 해제하도록 설정할 수 있습니다. 사용자가 파일 액세스 등 원하는 작업을 수행하려면 사전 인증이 필요합니다.
네트워크 관리자는 SAML을 이용해 사용자를 중앙에서 관리할 수 있습니다. 비밀번호 하나로 필요한 서비스에 모두 액세스할 수 있으며 기업의 보안도 강화할 수 있습니다.
- SAML 워크플로우
요청: 사용자가 "로그인" 버튼을 누름
검증: SAML과 아이덴티티 공급업체가 인증을 위해 연결된다.
로그인: 사용자 이름과 비밀번호 데이터를 입력하는 창이 표사
토큰 생성: 사용자가 정보를 올바르게 입력하면 SAML 토큰이 서비스 공급업체에게 전송되어 사용자가 서버에 로그인할 수 있게 됩니다.
서비스 공급업체와 브라우저, 그리고 아이덴티티 공급업체는 이러한 워크플로우를 통해 정보를 원활하게 주고받을 수 있다. 하지만 정보가 보통 몇 초만에 처리되기 때문에 사용자는 정보 처리에 따른 시간 지연을 느끼지 못한다고 한다.
출처 : https://www.okta.com/kr/identity-101/saml-vs-oauth/
=> 일반적인 회사에서 사용하는 인증 방식인 것 같다. 하지만 핵심은 다음에 나올 OAuth 인증 방식이다. (ex : Google Login, Kakao Login)
3. OAuth
- 사전적 정의 :
OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상의 자신들의 정보에 대해 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준이다.
- Resource Owner : 최종적인 사용자이며, 인증된 사용자를 대신하여 애플리케이션이 접근 권한을 요청하는 대상입니다. 자원 소유자는 자원의 실제 소유자이다.
- Client : Resource Owner가 소유한 리소스에 접근하고자 하는 애플리케이션이나 서비스로서, 보통 웹 애플리케이션, 모바일 애플리케이션, 서버 애플리케이션 등이 될 수 있다. 클라이언트는 자원에 직접 접근할 권한이 없으므로, Resource Owner의 권한을 대신 받아서 접근하는 구조이다.
동작 과정 설명
(1)
Resource Owner가 우리가 설계한 서비스의 '구글로 로그인하기' 등의 버튼을 클릭해 로그인을 요청한다.
(2)
Client는 OAuth 프로세스를 시작하기 위해 Resource Owner의 브라우저를 Authorization Server로 보냅니다.
Client는 이때 Authorization URL에 response_type, client_id, redirect_uri, scope 등의 매개변수를 쿼리 스트링으로 포함하여 보냄
- response_type : 반드시 code로 값을 성정해야 합니다.
인증이 성공할 경우 Client는 후술할 Authorization Code를 받는다.
- client_id : 웹 서비스를 Resource Server에 등록했을 때 발급받은 Client ID을 의미
- redirect_uri : 웹 서비스를 Resource Server에 등록했을 때 등록한 redirect URI을 의미
- scope : Client가 부여받은 리소스 접근 권한을 의미
(3) ~ (4) : 로그인 페이지 제공 및 ID/PW 입력
Client 로부터 Authorization URL로 이동된 Resource Owner는 제공된 로그인 페이지에서 ID/PW을 입력하여 인증을 한다.
(카카오 로그인 페이지, 구글 로그인 페이지)
(5) ~ (6) : Authorization Code 발급 및 Redirect URI로 리다이렉트
Authorization URL에서 인증이 성공했다면, Authorization server는 기존에 설정한 Redirect URL에 Authorization Code 를 포함하여 사용자를 리다이렉션 시킨다.
Authorization code란 리소스 접근을 위한 Access Token을 획득하기 위해 사용하는 임시 코드이며, 수명은 매우 짧다.
(7) ~ (8) : Authorization Code와 Access Token 발급
Client는 다시 Authorization Server에 Authorization Code를 전달하고, Access Token을 발급받는다.
Client는 자신이 발급받은 Resource Owner의 Access Token을 데이터베이스에 저장하고, 이후 Resource Server에서 Resource Owner의 리소스에 접근하기 위해 Access Token을 사용한다.
Access Token는 유출되어서는 안된다.
(9) : 로그인 성공
위 과정을 모두 성공적으로 마치면 Client는 Resource Owner에게 로그인이 성공하였음을 알립니다.
이후 Access Token을 가지고 접근 가능한 Resource 에 접근할 수 있게된다.
(10) ~ (13) : 서비스 요청 및 Access Token을 이용하여 리소스 접근 및 이용
이제 Access Token을 발급 받았기 때문에 정해진 권한 내에서 서비스를 이용 할 수 있다.
