[F-Lab 모각코 챌린지 52일차] Spring Security, OAuth

부추·2023년 7월 22일
0

F-Lab 모각코 챌린지

목록 보기
52/66

1. Spring Security

Spring Security?

: Spring 환경 안에서 authentication, authorization을 진행하는 하위 프레임워크이다. authentication은 유저가 제시한 ID와 password에 따라 이 유저가 해당 서비스에 등록된 유저인지, 정말 그 유저가 맞는지 확인하는 과정이고 authorization은 유저의 권한이 현재 유저가 서비스에서 행하려는 행위의 권한이 있는지 확인하는 과정이다.

spring security의 로직과 기능들은 유저의 request가 dispatcher servlet으로 가기 전 filter 단계에서 이뤄지므로 만약 권한이 없는 유저가 security 하에 보호된 페이지에 요청을 보내면 servlet container에게 닿지도 못한다. spring 환경의 handler나 controller에 설정해놓은 스프링 프레임워크의 기능들은 쓸 수 없다는 뜻이다.


동작과정

  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. Provider는 UserDetailService를 통해 token의 credential과 DB에서 찾은 ID, PW를 비교하여 인증을 진행한다. 실질적인 인증 과정이라 할 수 있다. ID가 존재하지 않으면 UserNotFoundException을, 비밀번호가 맞지 않아 실패하면 BadCrendentialException을 던진다.
  6. 인증이 성공하면 성공 sign이 추가된 Authentication Token이 AuthenticationManager에게 반환된다.
  7. signed token이 AuthenticationFilter에 도착하고, AuthenticationFilter는 해당 토큰을 LoginSuccessHandler에게 전달한다.
  8. Handler는 토큰에 저장된 유저정보인 Authentication 객체를 security context에 등록한다.

Authentication 객체엔 아이디를 뜻하는 Principle, 비밀번호인 Credential, 권한을 뜻하는 Role이 존재한다. 이후에 유저로부터 요청이 들어오면 세션에 있는 SecurityContextHolder의 auth 정보가 권한이 필요한 페이지에 접근할 때 이용된다.



2. OAuth2

OAuth?

OAuth 자체는 '인증을 위한 표준 프로토콜'이다. 특정 서비스에서 third party application의 기능을 이용할 때 해당 어플리케이션의 access token을 받아 서비스에서 각 유저에 맞는 어플리케이션의 정보와 기능들을 제공할 수 있게 해준다.

토스, 페이코 등의 결제 앱을 통한 결제나 사용자 정보에 맞는 구글 캘린더 연동, 트위터나 인스타그램 게시글 업로드 등의 상황에서 사용하는 기능으로 생각하면 된다.

쇼핑몰 등에서 사용하는 "구글로 로그인하기", "카카오로 시작하기", "네이버 페이를 통한 결제" 등의 소셜 로그인 역시 OAuth 프로토콜을 기반으로 한 로그인 서비스이다.


OAuth2 기반 사용자 인증 진행 과정

OAuth2에서 기본적으로 가장 많이 이용되는 Authorization Code Grant 방식을 통한 소셜 로그인 과정을 설명하겠다. 그 전에 헷갈릴 수도 있는 OAuth2의 기본 용어들을 정리하고 시작하자!
로그인이 필요한 쇼핑몰 서비스에서의 구글 이메일을 이용한 로그인 및 구글 서비스 이용을 생각해보자.

  1. 사용 요청 : Resouce Owner(유저)가 클라이언트(쇼핑몰)에게 Authorization Server(구글 이메일)를 이용하여 로그인할 것을 요청한다.
  2. 권한 부여 승인 코드 요청 : 클라이언트(쇼핑몰)는 authorization server에 클라이언트의 ID(해당 쇼핑몰임을 특정할 수 있는 ID) 정보를 담아 유저의 로그인 요청이 들어왔음을 알린다.
  3. 로그인 : Authorization 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 이용을 관리한다는 일련의 동작 과정을 확인할 수 있다.

profile
부추튀김인지 부추전일지 모를 정도로 빠싹한 부추전을 먹을래

0개의 댓글