[스프링부트와 AWS로 혼자 구현하는 웹 서비스] Spring Security와 Spring Security Oauth2 Client

세이라·2023년 7월 26일
Spring스프링부트와 AWS로 혼자 구현하는 웹 서비스
0

[스터디] 스프링부트와 AWS로 혼자 구현하는 웹 서비스

목록 보기
16/23

스터디를 통해 스프링부트와 AWS로 혼자 구현하는 웹 서비스(저자 이동욱) 서적을 공부하는 중입니다.

공부/실습한 내용을 정리한 포스팅입니다.
책에 모르는 부분이 있으면 구글링하거나 챗gpt에 물어봐서 보충하였습니다.
(아직 초보라 모르는 부분이 많아 이것저것 다 적었습니다.)

참고한 사이트 출처는 포스팅 맨 하단에 적었습니다.

소셜 로그인 기능

  • 로그인을 직접 구현할 경우, 배보다 배꼽이 커지는 경우가 많기 때문
  • 직접 구현 시, 로그인 시 보안 / 회원가입 시 이메일 혹은 전화번호 인증 / 비밀번호 찾기 / 비밀번호 변경 / 회원정보 변경 모두 구현. 소셜 로그인 구현 시 앞의 기능을 모두 구글, 페이스북 등에 맡기면 됨.

Spring Security

  • 막강한 인증(Authentication)과 인가(Authorization)(OR 권한부여) 기능을 가진 프레임워크.
  • Spring 기반의 Application에서는 보안을 위한 표준.
    : Inteceptor와 Filter 기반의 보안 기능을 구현하는 것보단 Spring Security를 통해 구현하는 것을 적극적으로 권장.
  • Spring의 대부분 프로젝트(Mvc, Data, Batch 등)처럼 확장성을 고려한 프레임워크다 보니 다양한 요구사항을 손쉽게 추가하고 변경 가능.

※ 인증이란 사용자의 신원을 검증하는 프로세스를 뜻함. 가장 간단한 예시로는 ID, PW 통해 로그인하는 행위를 인증이라 할 수 있음. 인가는 인증 이후의 프로세스로 인증된 사용자가 어떠한 자원에 접근할 수 있는지를 확인하는 절차.

OAuth

  • Open Authentication2의 약자. 인증 및 권한 획득을 위한 업계 표준 프로토콜.
  • 구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제 3자 클라이언트(서비스)가 사용자의 접근 권한을 위임받을 수 있음.
  • OAuth2는 보안 수준이 어느정도 검증된 플랫폼의 API를 이용하여 사용자 인증과 리소스에 대한 권한 획득을 할 수 있도록 해주는 역할을 하며, 대부분의 영향력 있고 OAuth2 인증을 제공하는 플랫폼들은 모두 OAuth2 규칙을 지키는 API 제공.
  • 사용자 입장에선 접근하려는 웹 사이트에 비밀번호를 제공하지 않고 타 플랫폼의 연결을 통해 인증 및권한을 부여받을 수 있어 편리.

OAuth 주체

Resource Owner

  • 리소스 소유자. 제 3자 클라이언트(서비스)를 이용하면서 구글,페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자.

Authorization & Resource Server

  • Authorization server는 Resource Owner를 인증하고, 제 3자 클라이언트(서비스)에게 액세스 토큰을 발급해주는 서버. Resource Server는 구글,페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 의미.
    (하나의 서버로 구성할 수도 있고, 별개의 서버로 구성할 수도 있음)

Client

  • Resource Server의 자원을 이용하고자 하는 서비스.
    (Resource Server와 Authorization Server 입장에선 자원을 이용하고자 하는 서비스가 Client이기 때문에 Client라 불림.)

애플리케이션 등록

  • OAuth 2.0 서비스 이용하기 전에, Client를 Resource Server에 등록해야 하며 Redirect URI를 등록해야 함.
    ※ Redirect URI : OAuth 2.0 서비스에서 인증을 마치고 리디렉션 시킬 위치
    (사전에 등록된 Redirect URI로만 리디렉션. 승인되지 않은 URI로 리디렉션 될 경우, Authorization Code를 중간에 탈취당할 위험이 있기 때문. htts만 허용되지만 루프백(localhost)의 경우, 예외적으로 http 허용)
  • 등록 과정을 마친 후, Client ID와 Client Secret을 얻을 수 있음.
    발급된 Client ID와 Client Secret는 액세스 토큰을 획득하는데 사용됨.
    Client Secret의 경우, 보안을 위해 절대 유출되어서는 안됨.

동작 매커니즘

  1. 로그인 요청
    : Resource Owner가 '구글로 로그인하기' 등의 버튼을 클릭하여 로그인 요청. Client는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 보냄.
    이때, Client는 Authorizaion Server가 제공하는 Authorization URL에 response_type, client_id, redirect_uri, scope 등의 매개변수를 쿼리 스트링으로 포함하여 보냄.
    resopose_type은 반드시 code로 설정해야 함.
    (인증이 성공할 경우 Authorization Code를 얻을 수 있음.)

  2. 로그인페이지 제공, ID/PW 제공
    : Client가 빌드한 Authorization URL로 이동된 Resource Owner는 제공된 로그인 페이지에서 ID와 PW 등을 입력하여 인증.

  3. Authorizaiton Code 발급, Redirect URI 리디렉트.
    : 인증 성공 시, Authorization Server는 제공된 Redirect URI로 Redirect 시킴.
    이때, Redirect URI에 Authorization Code 포함하여 Redirect 시킴. 구글의 경우, Code를 쿼리스트링에 포함.

※ Authorization Code - Client가 Access Token을 획득하기 위해 사용하는 임시코드. 이 코드는 수명이 매우 짧음.(일반적으로 1~10분)

  1. Authorization Code와 Access Token 교환
    : Client는 Authorization Server에 Authorizaiont Code를 전달하고, Access Token을 응답 받고 저장.
    이후, Resource Server에서 Resource Owner 리소스를 접근하기 위해 Access Token 사용. (유출되어선 안되므로, 제 3자가 가로채지 못하도록 HTTPS 연결을 통해서만 사용될 수 있음.)

※ Authorization Code와 Access Token 교환은 token 엔드 포인트에서 이뤄짐.
token 엔드포인트에서 Access Token 발급받기 위한 HTTP요청은 application/x-www-form-urlencoded의 형식에 맞춰 전달.
필수 전달 매개변수는 grant_type(authorization_code여야 함), code(발급 받은 Authorization Code, redirect_uri, client_id, client_secret이다.

  1. 로그인 성공
    : Client가 Resource Owner에게 로그인 성공 사실을 알림.

  2. Access Token으로 리소스 접근
    : 이후 Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에게 요청. 그럼 Client는 위 과정에서 발급하고 저장해둔 Resource Owner의 Access Token을 사용하여(API 호출) 제한된 리소스를 접근하여 Resource Owner에게 자사 서비스 제공.

스코프

  • OAuth 2.0은 스코프라는 개념을 통해서 리소스에 대한 Client의 접근 범위를 제한할 수 있음.
  • 스코프는 여러 개가 될 수 있으며, 대소문자를 구분하는 문자열을 공백으로 구분하여 표현. 문자열은 OAuth 2.0 인증 서버에 의해 정의.

Authorization Code 필요 이유

  • Redirect URI로 데이터 전달할 방법은 URL 쿼리스트링으로 데이터를 실어 전달하는 방법 밖에 없음. 브라우저를 통해 데이터가 노출되므로, 절대 노출하면 안되는 Access Token을 노출 시킬 수 없으므로 Authorization 사용.

Access Token

  • 계정의 보안 권한을 제 3자에게 넘겨준다는 암호문 형태의 증서

SpringBoot 1.5 VS SpringBoot 2.0

  • SpringBoot 1.5에서의 OAuth2 연동 방법이 2.0에서는 크게 변경되었지만, 설정방법에 크게 차이가 없음. 이는 spring-security-oauth2-autoconfigure 라이브러리 덕분.
    : spring-security-oauth2-autoconfigure 라이브러리를 사용할 경우 SpringBoot2에서도 1.5에서 쓰던 설정을 그대로 사용할 수 있음.
    새로운 방법을 쓰기보다는 기존에 안전하게 작동하던 코드를 사용하는 것이 더 확실하므로 많은 개발자가 이 방식을 사용해 옴.
  • SpringBoot2에서는 Spring Security Oauth2 Client 라이브러리 사용
    - Spring Security Oauth2 Client 사용해야 하는 이유
    - Spring 팀에서 기존 1.5에서 사용되던 spring-securiy-oauth 프로젝트는 유지 상태로 결정. Spring에서 마이그레이션을 적극 권장.
    - SpringBoot용 라이브러리(starter) 출시
    - 기존에 사용하던 방식은 확장 포인트가 적절하게 오픈되어 있지 않아 직접 상속하거나 오버라이딩 해야 하고 신규 라이브러리의 경우 확장 포인트를 고려하여 설계된 상태.

    Support Lifetime for Spring Security OAuth 2.x
    At the start of 2018, we announced the Spring Security OAuth project is officially in maintenance mode. We’ve already discontinued support for 2.0.x, in line with Boot’s 1.x End-of-Life (EOL), as well as 2.1.x and 2.2.x. And our plan is to discontinue the remaining support in the near future.
    The currently supported branches are 2.3.x and 2.4.x. The 2.3.x line will reach EOL in March 2020. We will support the 2.4.x line at least one year after reaching feature parity.
    To that end, with the release of Spring Security 5.2, we are strongly encouraging users to start migrating their legacy OAuth 2.0 client and resource server applications to the new support in Spring Security 5.2.
    Spring Security OAuth 2.0 Roadmap Update

  • SpringBoot2 방식인지 확인해보기 위해선 아래의 두 가지 확인
    • spring-security-oauth2-autoconfigure 라이브러리 썼는지 확인
    • application.properties 혹은 application.yml 정보 차이
      • SpringBoot 1.5 방식에선 url 주소 모두 명시. 2.0방식에선 client 인증 정보만 입력. 1.5버전에서 직접 입력했던 값들은 enum으로 대체

(참고 사이트) [Spring Boot] application.properties와 application.yml의 차이점

※ CommonOAuth2Provider enum
: 구글, 깃허브, 페이스북, 옥타 등 Oauth2 제공자 기본 설정값은 Spring Security에서 이 enum을 통해서 제공.
이외의 다른 소셜 로그인을 추가한다면 직접 다 추가해야 함.

application.properties 파일에서 Client 자격 증명 읽고
나머지 Client 속성에 대해 이미 Spring Security에 정의한CommonOauth2Provider 열거형을 사용.

(참고문서) CommonOAuth2Provider (spring-security-docs 6.1.1 API)

Spring Security OAuth2 Client

  • Spring에서 OAuth 2.0 프로토콜을 사용하여 인증 수행하는 Client.
    OAuth 2.0 서비스에 대한 인증을 처리하기 위한 모듈.
  • OAuth 2.0 프로토콜을 사용하여 인증하는 Client 구현하는데 필요한 기능 제공.
    이를 통해 서비스 제공자의 API를 사용하고 인증된 사용자 정보를 가져올 수 있음.

출처

인증/인가는 어디에 어떻게 구현해야 할까? - 지마켓 기술블로그
OAuth 2.0 개념과 동작원리
Access Token과 Refresh Token이란 무엇인가?
[Spring Boot] OAuth2 소셜 로그인 가이드 (구글, 페이스북, 네이버, 카카오)
[Java] Spring Boot OAuth 2 Client 이해하기 -1 : 정의, 흐름, 인증방식 종류
[Spring Security] OAuth 네이버 로그인하기
스프링 시큐리티 5 – OAuth2 로그인

profile
세이라
이전 포스트

[스프링부트와 AWS로 혼자 구현하는 웹 서비스] Mustache로 게시글 수정,삭제 화면 만들고 게시글 수정,삭제 기능 넣기

다음 포스트

[스프링부트와 AWS로 혼자 구현하는 웹 서비스] 구글 서비스 등록 및 설정

0개의 댓글