1. Spring Security
# Spring Security?
: Spring 환경 안에서 authentication, authorization을 진행하는 하위 프레임워크이다. authentication은 유저가 제시한 ID와 password에 따라 이 유저가 해당 서비스에 등록된 유저인지, 정말 그 유저가 맞는지 확인하는 과정이고 authorization은 유저의 권한이 현재 유저가 서비스에서 행하려는 행위의 권한이 있는지 확인하는 과정이다.
spring security의 로직과 기능들은 유저의 request가 dispatcher servlet으로 가기 전 filter 단계에서 이뤄지므로 만약 권한이 없는 유저가 security 하에 보호된 페이지에 요청을 보내면 servlet container에게 닿지도 못한다. spring 환경의 handler나 controller에 설정해놓은 스프링 프레임워크의 기능들은 쓸 수 없다는 뜻이다.
이와 관련해서 내가 삽질한 내용은... ㅜㅜ아래와 같다.
Spring Security의 Security Filter Chain 관련 Exception handling하기
Security Filter Chain에 등록된 authorization에 맞지 않는 client request가 들어왔을 때, 내가 해당 요청을 핸들링 하고 싶었다. Spring에서 상식적(?)으로 알려진 Exception 처리 방법이다.. @ControllerAdvice @Slf4j pub
buchu-doodle.tistory.com
# security 진행 과정
1: user의 HTTP 요청이 spring security의 authentication filter에 도착한다.
2: unsigned authentication token을 발행한다.
3: 인증을 처리하는 authenticate() method가 존재하는 AuthenticationManager에게 토큰이 전달된다.
4: AuthenticationManager는 여러 개의 AuthenticationProvider들을 가지고 있는데, 해당 security 환경에 등록된 provider 중 방금 발행된 token에 맞는 provider에게 token을 전달하여 인증을 명령한다. 이 과정은 for 문을 통해 진행된다.
5,6,7 : Provider는 UserDetailService를 통해 token의 credential과 DB에서 찾은 ID, PW를 비교하여 인증을 진행한다. 실질적인 인증 과정이라 할 수 있다. ID가 존재하지 않으면 UserNotFoundException을, 비밀번호가 맞지 않아 실패하면 BadCrendentialException을 던진다.
8 : 인증이 성공하면 sign이 추가된 Authentication Token이 AuthenticationManager에게 반환된다.
9 : signed token이 AuthenticationFilter에 도착하고, AuthenticationFilter는 해당 토큰을 LoginSuccessHandler에게 전달한다.
10 : Handler는 토큰에 저장된 유저정보인 Authentication 객체를 security context에 등록한다.
이후에 유저로부터 요청이 들어오면 세션에 있는 SecurityContextHolder의 auth 정보가 권한이 필요한 페이지에 접근 할 때 이용된다.
인증 각 단계의 상세한 code implementation을 확인해 볼 수 있는 소중한 블로그 글을 소개한다!
[SpringBoot] Spring Security 처리 과정 및 구현 예제
이번에는 Spring Security가 어떤 과정으로 Authentication 처리를 하는지, 그리고 실제로 어떻게 구현하는지 알아보도록 하자. 1. Spring Security 처리 과정 Spring Security 아키텍쳐는 위와 같으며 각각의 처리
mangkyu.tistory.com
+) Token 기반 인증 방식
위 방법은 session을 이용한 인증 방식이다. 클라이언트의 쿠키에 session id를 저장해놓고, 해당 id에 맞는 서버의 session storage data를 제공하는 형식이다.
사용자 인증 정보를 전부 세션에 보관하여 서버의 램에 부담을 주는 세션 기반 인증 방식과 달리, 토큰 기반 인증 방식은 서버에 사용자 정보를 저장해 둘 필요 없이 요청이 들어올 때만 토큰의 유효성 검사를 시행하면 된다는 장점이 있다. 무상태성(stateless)을 유지해 서버 부담을 덜었다는 것이 큰 특징인듯.
보통 토큰에는 유저 자체를 의미하는 Principle(가장 기본적으로는 ID, 더해서는 security 환경 서비스에 필요한 여러가지 유저 정보를 담고있음) + 실제 그 유저가 맞는지 확인하기 위한 Crendential(가장 기본적으로는 Password) + authorization에 필요한, 해당 유저의 권한인 Role을 담고 있다. credential을 기반으로 해당 유저의 authentication이 끝나면 서버가 토큰에 sign을 하고, 그 뒤엔 세션에 사용자 정보를 보관할 필요 없이 요청의 헤더에 signed token을 실어 날리면 서비스는 sign의 유효성만 검사하는 것이 토큰 기반 인증 방식의 핵심이다.
이는 나중에 JWT 기반 인증을 공부할 때 따로 더 다뤄보도록 하겠다.. (내용 자체가 옮겨질 수 있음)
2. OAuth2
# OAuth2?
인증을 위한 표준 프로토콜 이라는듯 하다. 특정 서비스에서 third party application의 기능을 이용할 때 해당 어플리케이션의 access token을 받아 서비스에서 각 유저에 맞는 어플리케이션의 정보와 기능들을 제공할 수 있게 해준다.
토스, 페이코 등의 결제 앱을 통한 결제나 사용자 정보에 맞는 구글 캘린더 연동, 트위터나 인스타그램 게시글 업로드 등의 상황에서 사용하는 기능으로 생각하면 된다.
쇼핑몰 등에서 사용하는 "구글로 로그인하기", "카카오로 시작하기", "네이버 페이를 통한 결제" 등의 소셜 로그인 역시 OAuth2 프로토콜을 기반으로 한 로그인 서비스이다.
# OAuth2 기반 사용자 인증 진행 과정
OAuth2에서 기본적으로 가장 많이 이용되는 Authorization Code Grant 방식을 통한 소셜 로그인 과정을 설명하겠다. 그 전에 헷갈릴 수도 있는 OAuth2의 기본 용어들을 정리하고 시작하자!
| Resource Owner | 간단하게 유저. application에 존재하는 resouce를 가지고 있는 주체. |
| Client | OAuth2 서비스를 이용하는 클라이언트. 보통 개발자들이 개발하고 있는 쇼핑몰 등을 생각하면 된다. |
| Authorization Server | 실제 auth를 진행하는 서버. 로그인 정보의 유효성을 검사하고, 성공할 시 access token을 제공한다. |
| Resource Server | 간단하게 구글이나 네이버 등의 회사. 클라이언트에게 resource owner에 맞는 data를 제공해준다. |
로그인이 필요한 쇼핑몰 서비스에서의 구글 이메일을 이용한 로그인을 생각해보자.
1. 사용 요청 : Resouce Owner(유저)가 클라이언트(쇼핑몰)에게 Resource Server(구글 이메일)를 이용하여 로그인할 것을 요청한다.
2. 권한 부여 승인 코드 요청 : 클라이언트(쇼핑몰)는 authorization server에 클라이언트의 ID(해당 쇼핑몰임을 특정할 수 있는 ID) 정보를 담아 유저의 로그인 요청이 들어왔음을 알린다.
3. 로그인 : Authrization Server가 제공한 구글 로그인 폼에 유저가 성공적으로 로그인한다.
4. 권한 부여 승인 코드 전달 : Authorization Server가 클라이언트(쇼핑몰)에 유저의 구글 로그인이 성공했다는 코드를 전한다.
5. Access Token 요청 : 클라이언트(쇼핑몰)가 승인 코드를 가지고 Authorization Server에 클라이언트 서비스에서 사용할 Access Token을 줄 것을 요청한다.
6. Access Token 전달 : 클라이언트(쇼핑몰)에 OAuth2 Token이 전달되면 클라이언트(쇼핑몰) 단에서 이를 활용한 auth를 진행한다.
-> 소셜 로그인 기능에선 이 단계에서 Resouce Server(구글)가 준 유저 정보로 클라이언트 로그인을 처리하면 끝이다.
7. 보호된 자원 요청 : 발행된 Access Token으로 Resource Server(구글)의 기능이나 자원을 요청한다.
8. 요청 자원 전달 : Resource Server가 Access Token의 권한을 확인하고 요청하는 정보를 응답한다.
Payco의 develop 가이드 사이트에 oauth2를 이용한 페이코 결제 서비스 이용에 관한 실제 예시를 확인할 수 있다. 위의 설명과는 상세한 동작 과정이 약간 다른데 전체적인 큰 그림은 같다.
callback URL은 로그인 성공 후 redirect할 URL이다. 보통 클라이언트(서비스) 단에서 authorization code가 필요한 URL을 직접 등록하게 된다. 유저의 Resouce Server 정보를 담은 Authorization Code가 callback URL을 통해 클라이언트(위의 그림에선 서비스)로 전달되고, 서비스가 Access Token을 가지고 유저의 third party application 이용을 관리한다는 일련의 동작 과정을 확인할 수 있다.
