주의
이 책은 Spring Security 5 버전을 기준으로 작성되었으므로, Spring Boot 3.X 버전에서는 일부 클래스가 더 이상 사용되지(deprecated) 않을 수 있습니다.
1. OAuth 2 프레임워크
- OAuth 2를 권한 부여 프레임워크라고 부르는 경우가 많으며, 타사 웹사이트나 웹이 리소스에 접근할 수 있게 허용하는 것이 주목적
- OAuth 2는 특정 구현이나 라이브러리가 아니라는 점이 중요
- 여태까지 다룬 HTTP Basic 인증 방식에는 두 가지 고려할 문제가 있음
- 모든 요청에 자격 증명을 보내야 함
- 사용자의 자격 증명을 별도의 시스템이 관리해야 함
- 모든 요청에 대한 자격 증명을 보내는 방식은 일반적으로 다음을 의미하기 때문에 바람직하지 않음
- 네트워크를 통해 자격 증명이 자주 공유됨
- 클라이언트가 자격 증명을 저장해 인증 및 권한 부여 요청과 함께 자격 증명을 서버에 보낼 수 있게 함
- 이러한 두 요소는 자격 증명을 취약하게 만들고 보안을 약화하기 때문에 애플리케이션 아키텍처에서 제거하는 것을 권장
- 많은 경우 별도의 시스템에서 사용자 자격 증명을 관리하는 것이 바람직함
- 모든 애플리케이션의 자격 증명을 모두 따로 구성하고 이용해야 한다고 가정했을 때 자격 증명을 관리하는 책임을 시스템의 한 구성 요소에 격리할 수 있다면 좋을 것
- 해당 접근 방식을 이용하면 같은 사용자를 나타내는 중복된 자격 증명이 제거되므로 아키텍처가 더 간소화되고 유지 관리도 쉬워짐
2. OAuth 2 인증 아키텍처의 구성 요소
- OAuth 2 구성 요소는 다음을 포함함
- 리소스 서버: 사용자가 소유한 리소스를 호스팅 하는 서버, 리소스는 사용자의 데이터이거나 사용자가 수행할 수 있는 작업일 수 있음
- 사용자 (리소스 소유자): 리소스 서버가 노출하는 리소스를 소유하는 개인, 일반적으로 사용자는 사용자 이름과 암호로 신원을 증명함
- 클라이언트: 사용자를 대신해 사용자가 소유한 리소스에 접근하는 애플리케이션, 클라이언트는 클라이언트 ID와 클라이언트 비밀을 이용해 신원을 증명 (이러한 자격 증명은 사용자 자격 증명과는 다름, 클라이언트는 요청할 때 자신을 증명하는 자체 자격 증명 필요)
- 권한 부여 서버: 클라이언트가 리소스 서버가 노출하는 사용자의 리소스에 접근할 권한을 부여하는 애플리케이션, 권한 부여 서버는 클라이언트가 사용자 대신 리소스에 접근 권한이 있다고 결정하며 토큰을 발급
- 클라이언트는 해당 토큰을 이용해 권한 부여 서버에서 권한을 받았음을 리소스 서버에 증명함
- 리소스 서버는 유효한 토큰이 있으면 클라이언트가 요청한 리소스에 접근하게 허용
3. OAuth 2를 구현하는 방법 선택
- OAuth 2를 이용한다는 것은 권한 부여에 토큰을 이용한다는 뜻
- 토큰을 얻은 후에는 특정 리소스에 접근할 수 있음
- OAuth 2는 grant라고 하는 토큰을 얻는 여러 방법을 제공하며 다음은 선택할 수 있는 가장 일반적인 OAuth 2 그랜트 유형
- 승인 코드
- 암호
- 갱신 토큰
- 클라이언트 자격 증명
3.1 승인 코드 그랜트 유형 (Authorization Code Grant Type)의 구현
- 승인 코드 그랜트 유형은 다음과 같이 작동함
- 인증 요청
- 액세스 토큰 획득
- 보호된 리소스 호출
1단계: 승인 코드 그랜트 유형으로 인증 요청 수행
- 클라이언트는 사용자가 인증해야 하는 권한 부여 서버의 엔드포인트로 사용자를 리다이렉트함
- 앱 X에서 보호된 리소스에 접근해야 한다고 가정했을 때 앱 X는 리소스에 접근하기 위해 인증해야 하므로 사용자가 자격 증명을 입력할 수 있는 권한 부여 서버의 로그인 양식이 있는 페이지를 염
- 기술적으로 보면 사용자를 권한 부여 서버로 리다이렉트 할 때 클라이언트는 다음 세부 정보가 포함된 요청 쿼리로 권한 부여 엔드포인트를 호출함
- response_type: 클라이언트 코드를 기대한다는 것을 권한 부여 서버에 알리는 값인 code를 포함, 클라이언트가 액세스 토큰을 얻으려면 코드가 필요함
- client_id: 애플리케이션 자체를 식별하는 클라이언트 ID 값
- redirect_uri: 인증 성공 후 사용자를 리다이렉트할 위치를 권한 부여 서버에 알려줌, 때때로 권한 부여 서버는 각 클라이언트의 기본 리다이렉트 할 URI를 이미 알고 있으므로 클라이언트는 리다이렉트 URI를 보낼 필요 없음
- scope: 허가된 권한과 비슷
- state: CSRF 보호를 위한 CSRF 토큰 정의
- 인증에 성공하면 권한 부여 서버는 리다이렉트 URI로 클라이언트를 다시 호출하고 코드와 상태 값을 제공함
- 클라이언트는 상태 값이 요청에 보낸 것과 같은지 검사해 다른 사람이 리다이렉트 URI를 호출하려는 것이 아닌지 확인
- 클라이언트는 코드를 이용해 다음의 2단계로 액세스 토큰을 얻음
2단계: 승인 코드 그랜트 유형으로 액세스 토큰 얻기
- 1단계에서 생성된 코드는 사용자가 리소스에 접근할 수 있도록 사용자가 인증했다는 클라이언트의 증명이며 이것을 승인 코드 그랜트 유형이라고 부르는 이유
- 이제 클라이언트는 토큰을 얻기 위해 코드로 권한 부여 서버를 호출함
- 인증 서버를 두 번 호출하는 이유는 다음과 같음
- 권한 부여 서버는 사용자가 직접 상호 작용했다는 증거로 첫 번째 코드를 생성
- 클라이언트는 해당 코드를 받고 이를 자신의 자격 증명과 함께 이용해 액세스 토큰을 받기 위해 인증을 함
- 클라이언트는 이 두 번째 토큰을 이용해 리소스 서버의 리소스에 접근
- 권한 부여 서버가 곧바로 액세스 토큰을 반환하지 않는 이유는 실제 클라이언트에서 받았는지 확인되지 않은 액세스 토큰으로 리다이렉트 URI를 곧바로 호출할 경우 덜 안전하기 때문
- 먼저 승인 코드를 보내도록 하므로 클라이언트는 액세스 토큰을 얻기 위해 자격 증명으로 자신이 누구인지 다시 증명해야 함
- 암시적 그랜트 유형 (implicit grant type)은 곧바로 액세스 토큰을 반환하지만 위와 같은 이유 때문에 대부분의 권한 부여 서버에서 허용되지 않음
- 2단계로 돌아가서 클라이언트는 권한 부여 서버에 요청하고 해당 요청에는 다음 세부 정보가 들어 있음
- code: 1단계에서 받은 승인 코드, 이는 사용자가 인증받았음을 증명
- client_id 및 client_secret: 클라이언트의 자격 증명
- redirect_uri: 1단계에서 검증에 사용된 것과 같음
- grant_type: 이용된 흐름의 유형을 식별하며 authorization_code 값을 가짐, 서버가 여러 흐름을 지원할 수 있으므로 항상 현재 실행된 인증 흐름이 무엇인지 지정하는 것이 필수적
- 서버는 이에 대한 응답으로 access_token을 반환하며 해당 토큰은 클라이언트가 리소스 서버에서 노출하는 리소스를 호출하는 데 사용할 수 있는 값
3단계: 승인 코드 그랜트 유형으로 보호된 리소스 호출
- 권한 부여 서버에서 액세스 토큰을 받고 나면 이제 클라이언트는 보호된 리소스를 호출할 수 있음
- 클라이언트는 리소스 서버의 엔드포인트를 호출할 때 권한 부여 요청 헤더의 액세스 토큰을 사용
3.2 암호 그랜트 유형 (Password Grant Type) 구현
- 해당 그랜트 유형을 리소스 소유자 자격 증명 그랜트 유형이라고도 함
- 이 흐름에서 애플리케이션은 클라이언트가 사용자 자격 증명을 수집하고 이를 이용해 인증하며 권한 부여 서버에서 액세스 토큰을 얻음
- 해당 인증 흐름은 클라이언트와 권한 부여 서버를 같은 조직에서 구축하고 유지 관리할 때만 이용함
- 책임 분리를 위해 인증 책임을 별도 마이크로서비스로 분리하기로 했고 시스템의 사용자는 리액트 프레임워크로 개발된 클라이언트 웹 애플리케이션이나 모바일 앱을 사용한다고 가정했을 때 사용자는 인증을 위해 동일한 시스템으로 리다이렉트 되었다가 다시 돌아오는 것이 이상하다고 생각될 확률이 높음
- 앞서 설명한 승인 코드 그랜트 시스템과 같은 흐름에서 위와 같은 상황이 발생할 수 있음
- 암호 그랜트 유형을 이용하면 대신 애플리케이션이 사용자에게 로그인 양식을 보여주고 클라이언트가 서버에 자격 증명을 보내 인증 과정을 처리함
- 암호 그랜트 유형은 다음과 같은 두 단계로 처리됨
- 액세스 토큰 요청
- 액세스 토큰을 이용해 리소스 호출
1단계: 암호 그랜트 유형으로 액세스 토큰 요청
- 클라이언트는 사용자 자격 증명을 수집하고 권한 부여 서버를 호출해 액세스 토큰을 얻음
- 클라이언트는 액세스 토큰을 요청할 때 다음 세부 정보를 함께 보냄
- grant_type: password 값을 가짐
- client_id 및 client_secret: 클라이언트가 자신을 인증하기 위한 자격 증명
- scope: 허가된 권한이라고 이해할 수 있음
- username 및 password: 사용자 자격 증명, 일반 텍스트 형식으로 요청 헤더의 값으로 전송됨
- 클라이언트는 응답으로 액세스 토큰을 받으며 이제 클라이언트는 액세스 토큰을 이용해 리소스 서버의 엔드포인트를 호출할 수 있음
2단계: 암호 그랜트 유형으로 액세스 토큰을 이용해 리소스 호출
- 액세스 토큰을 얻은 클라이언트는 해당 토큰으로 리소스 서버의 엔드포인트를 호출할 수 있으며 승인 코드 그랜트 유형을 이용할 때와 마찬가지로 권한 부여 요청 헤더에 액세스 토큰을 추가함
3.3 클라이언트 자격 증명 그랜트 유형 (Client Credentials Grant Type) 구현
- 해당 방식은 OAuth 2가 지원하는 가장 단순한 그랜트 유형이며 사용자가 관여하지 않을 때, 즉 두 애플리케이션 간의 인증을 구현할 때 이용할 수 있음
- 클라이언트 자격 증명 그랜트 유형을 처리하는 과정은 암호 그랜트 유형과 유사함
- 유일한 차이는 액세스 토큰을 요청할 때 사용자 자격 증명이 필요하지 않다는 것
- 이 그랜트 유형을 구현하는 단계는 다음과 같음
- 액세스 토큰 요청
- 액세스 토큰을 이용해 리소스 호출
1단계: 클라이언트 자격 증명 그랜트 유형으로 액세스 토큰 얻기
- 클라이언트는 액세스 토큰을 얻기 위해 다음 세부 정보와 함께 권한 부여 서버에 요청을 보냄
- grant_type: client_credentials 값을 가짐
- client_id 및 client_secret: 클라이언트 자격 증명을 나타냄
- scope: 허가된 권한을 나타냄
- 클라이언트는 응답으로 액세스 토큰을 받으며 이제 클라이언트는 액세스 토큰을 이용해 리소스 서버의 엔드포인트를 호출할 수 있음
2단계: 클라이언트 자격 증명 그랜트 유형으로 액세스 토큰을 이용해 리소스 호출
- 액세스 토큰을 얻은 클라이언트는 해당 토큰으로 리소스 서버의 엔드포인트를 호출할 수 있으며 승인 코드 그랜트 유형과 암호 그랜트 유형과 마찬가지로 권한 부여 요청 헤더에 액세스 토큰을 추가함
3.4 갱신 토큰 (Refresh Token)으로 새 액세스 토큰 얻기
- 토큰은 구현한 방식과 관계없이 만료될 수 있으며 토큰의 수명을 무한하게 만들 수도 있지만 가능하면 토큰이 최소한의 수명을 가지는 것을 권장
- 앱에서 만료되지 않는 토큰을 구현했다고 가정할 경우 클라이언트가 같은 토큰으로 리소스 서버의 리소스를 제한 없이 호출할 수 있음
- 하지만 토큰이 만료되지 않으면 누군가 토큰을 탈취한 뒤 리소스에 접근하는 데 이용할 수 있음
- 이러한 부작용을 방지하기 위해 토큰의 수명을 짧게 만들어야 하며 그러면 만료된 토큰을 더는 이용할 수 없고 클라이언트는 다른 액세스 토큰을 얻어야 함
- 이용된 그랜트 유형에 따라 클라이언트는 새 액세스 토큰을 얻기 위해 흐름을 다시 실행할 수 있음
- i.g. 그랜트 유형이 인증 코드라면 클라이언트는 사용자를 권한 부여 서버로 리다이렉트 하며 사용자는 다시 자신의 사용자 이름과 암호를 입력해야 하는데 이는 사용자 친화적인 방식이 아님 (토큰의 수명이 20분이고 온라인 앱으로 두 시간 동안 작업한다고 가정할 경우 작업하는 동안 무려 6번이나 로그인 화면으로 리다이렉트 됨...)
- 권한 부여 서버는 재인증할 필요를 없애기 위해 액세스 토큰과는 값과 용도가 다른 갱신 토큰을 발행할 수 있으며 앱은 갱신 토큰으로 재인증 없이 새 액세스 토큰을 얻을 수 있음
- 갱신 토큰은 암호 그랜트 유형에서 재인증보다 이점이 있음
- 암호 그랜트 유형에서도 갱신 토큰을 이용하지 않으면 사용자에게 재인증하도록 요청하거나 사용자의 자격 증명을 저장해야 함
- 암호 그랜트 유형에서 사용자 자격 증명을 저장하는 것은 심각한 보안 허점 (사용자 이름과 암호를 저장하면 이러한 자격 증명을 노출하는 것)
- 갱신 토큰으로 위 문제를 쉽고 안전하게 해결 가능
- 자격 증명을 안전하지 않게 저장하거나 매번 사용자를 리다이렉트 할 필요 없이 갱신 토큰을 저장하고 필요할 때 이용해 새 액세스 토큰을 얻을 수 있음
- 갱신 토큰은 노출된 것이 확인되면 취소할 수 있으므로 암호 그랜트 유형에서 자격 증명이 노출되는 것보다 안전함
- 권한 부여 서버는 승인 코드나 암호 그랜트 유형과 같은 흐름을 사용할 때 액세스 토큰과 함께 갱신 토큰을 반환
- 클라이언트 자격 증명 그랜트 유형에는 사용자 자격 증명이 필요 없으므로 갱신 토큰도 사용되지 않음
- 갱신 토큰을 가진 클라이언트는 액세스 토큰이 만료될 때 다음 세부 정보가 포함된 요청을 발행함
- refresh_token 값을 가지는 grant_type
- 갱신 토큰의 값을 가지는 refresh_token
- 클라이언트의 자격 증명을 포함하는 client_id와 client_secret
- 같거나 더 작은 허가 권한을 정의하는 scope, 더 많은 권한을 부여해야 할 때는 재인증 필요
- 이 요청에 대한 응답으로 권한 부여 서버는 새 액세스 토큰과 새 갱신 토큰을 발행함
4. OAuth 2 허점
- OAuth 2도 다른 모든 소프트웨어 개발 영역과 마찬가지로 무적이 아님
- 반드시 인지해야 하고 애플리케이션을 구축할 때 고려해야 할 취약성이 있는데 가장 일반적인 사항은 다음과 같음
- 클라이언트에서 CSRF 이용: 애플리케이션이 CSRF 보호 메커니즘을 적용하지 않으면 사용자가 로그인했을 때 CSRF가 가능함
- 클라이언트 자격 증명 도움: 보호되지 않은 자격 증명을 저장하거나 전송할 경우 이를 공격자가 도용하는 위반이 발생할 수 있음
- 토큰 재생: 토큰은 OAuth 2 인증 및 권한 부여 아키텍처에서 리소스에 액세스 할 때 쓰는 열쇠, 문제는 해당 열쇠를 네트워크를 통해 보내는 동안 누군가 가로챌 수 있고 이렇게 도난당한 열쇠가 재사용될 수 있다는 점
- 토큰 하이재킹: 인증 프로세스를 방해하고 리소스에 액세스 하기 위한 토큰을 훔치는 것을 의미, 이는 또한 갱신 토큰을 이용하는 잠재적인 취약성이기도 한데, 갱신 토큰을 가로채고 새 액세스 토큰을 얻는 데 이용할 수 있기 때문
5. 간단한 SSO (Single Sign-On) 애플리케이션 구현
- SSO 애플리케이션은 이름이 의미하듯이 사용자가 권한 부여 서버를 통해 인증하면 앱이 갱신 토큰을 이용해 로그인 상태를 유지함
- 예제 애플리케이션은 깃허브를 권한 부여 및 리소스 서버로 이용하고 구성 요소와 승인 코드 그랜트 유형 간의 통신에 집중함
5.1 권한 부여 서버 관리
- 깃허브 같은 타사 서비스를 권한 부여 서버로 사용한다는 것은 애플리케이션이 직접 사용자를 관리하지 않으며 깃허브 계정이 있는 사람이라면 누구나 애플리케이션에 로그인할 수 있다는 뜻
- 다른 권한 부여 서버와 마찬가지로 깃허브는 토큰을 발행할 대상인 클라이언트 애플리케이션에 관해 알아야 함
- 클라이언트는 클라이언트 ID와 클라이언트 암호 (자격 증명)를 이용해 권한 부여 서버에 자신을 인증하므로 OAuth 애플리케이션을 깃허브 권한 부여 서버에 등록해야 함
- 이를 위해 다음 링크로 이동해서 간단한 양식을 작성하면 됨
- 새 OAuth 애플리케이션을 추가할 때는 애플리케이션의 이름, 홈페이지, 깃허브가 애플리케이션을 다시 호출할 링크를 지정해야 함
- 승인 코드 그랜트 유형은 클라이언트가 로그인할 사용자를 권한 부여 서버로 리다이렉트 한 다음 권한 부여 서버가 정의된 URL로 클라이언트를 다시 호출한다고 가정하기 때문에 콜백 URL을 정해야 함
- 양식을 입력하고 Register Application을 선택하면 깃허브는 클라이언트 ID와 클라이언트 비밀을 제공함
5.2 구현 시작
- 먼저 보호할 웹 페이지가 필요하므로 이를 위해 컨트롤러 클래스와 애플리케이션을 나타내는 간단한 HTML 페이지를 생성
- 이후 애플리케이션이 깃허브에서 로그인을 이용할 수 있도록 보안 구성을 설정하기 위해 WebSecurityConfigurerAdapter를 확장하고 configure(HttpSecurity http) 메서드를 재정의
- oauth2Login()이라는 메서드를 호출하는 것을 주목
- oauth2Login() 메서드를 호출할 때 프레임워크는 Oauth2LoginAuthenticationFilter를 필터 체인에 추가하며 해당 필터는 요청을 가로채고 OAuth 2 인증에 필요한 논리를 적용함
5.3 ClientRegistration 구현
- 현재 상태로 애플리케이션을 실행하면 main.html에 접근할 수 없는데 이유는 모든 요청에 대해 사용자가 인증해야 한다고 지정했지만 인증 방법을 제공하지 않았기 때문
- 따라서 깃허브가 우리 권한 부여 서버임을 설정해야 함
- 스프링 시큐리티는 여기에 이용할 수 있는 ClientRegistration 계약을 정의함
- ClientRegistration 인터페이스는 OAuth 2 아키텍처의 클라이언트를 나타내며 다음고 같은 클라이언트의 모든 세부 정보를 정의해야 함
- 클라이언트 ID와 비밀
- 인증에 이용되는 그랜트 유형
- 리다이렉트 할 URI
- 범위
- 다음 링크를 참고하여 ClientRegistration을 설정할 수 있음
- 스프링 시큐리티는 더 편하게 작업할 수 있도록 CommonOAuth2Provider라는 클래스를 정의하며 해당 클래스는 다음을 포함한 가장 일반적인 공급자에 대한 인증에 이용할 수 있는 ClientRegistration 인스턴스를 부분적으로 정의함
- 구글
- 깃허브
- 페이스북
- 옥타
- 일반적인 공급자에 대해서만 적용되는 제한이 존재하지만 아래 코드를 통해 인증 서버의 URL을 수동으로 찾아 설정할 필요가 없어 훨씬 깔끔한 것을 확인할 수 있음
- 일반적인 공급자가 아니라면 ClientRegistration을 완전히 정의하는 것 외에 다른 방법이 없음
5.4 ClientRegistrationRepository 구현
- 이제까지 ClientRegistration 계약을 구현해 스프링 시큐리티를 위해 OAuth 2를 나타내는 방법을 배웠는데 인증에 이용하도록 설정하는 방법도 알아야 함
- 이를 위해 스프링 시큐리티는 ClientRegistrationRepository 형식의 객체를 이용함
- ClientRegistrationRepository 인터페이스는 UserDetailsService 인터페이스와 유사함
- UserDetailsService 객체가 사용자 이름으로 UserDetails를 찾는 것처럼 ClientRegistrationRepository 객체는 등록 ID로 ClientRegistration을 찾음
- ClientRegistrationRepository 인터페이스를 구현해서 ClientRegistration 인스턴스를 찾을 위치를 프레임워크에 알릴 수 있음
- 스프링 시큐리티는 ClientRegistration의 인스턴스를 메모리에 저장하는 ClientRegistrationRepository의 구현체인 InMemoryClientRegistrationRepository를 제공
5.5 스프링 부트 구성의 순수한 마법
- 스프링 부트에는 속성 파일로 직접 ClientRegistration과 ClientRegistrationRepository 객체를 구축하는 기능이 있음
- 해당 접근법은 스프링 부트 프로젝트에서 드물지 않게 이용되며 다른 객체에 대한 작업에도 종종 이용됨
application.properties 예시
- 설정 파일에 클라이언트 ID와 클라이언트 비밀만 설정하면 공급자의 이름이 github이므로 스프링 부트는 CommonOAuth2Provider 클래스에서 URI와 관련된 모든 세부 정보를 가져오는 방법을 암
- 따라서 구성 클래스가 간단해짐
- ClientRegistration 및 ClientRegistrationRepository에 관한 세부 정보는 스프링 부트가 속성 파일을 바탕으로 자동으로 생성하므로 직접 지정할 필요가 없음
- 스프링 시큐리티에 알려진 일반적인 공급자가 아닌 다른 공급자를 이용하려면 spring.security.oauth2.client.provider로 시작하는 속성 그룹으로 권한 부여 서버에 관한 세부 정보도 지정해야 함
5.6 인증된 사용자의 세부 정보 얻기
- 스프링 시큐리티에서 인증된 사용자의 세부 정보는 SecurityContext에 저장됨
- 인증 프로세스가 끝나면 담당 필터가 Authentication 객체를 SecurityContext에 저장함
- 애플리케이션은 여기에서 사용자 세부 정보를 얻고 필요에 따라 이용할 수 있으며 OAuth2 인증에서도 마찬가지임
- 이 경우 프레임워크에 이용되는 Authentication 객체의 구현은 OAuth2AuthenticationToken이며 SecurityContext에서 직접 이를 가져오거나 스프링 부트가 엔드포인트의 매개 변수에 주입하게 할 수 있음
5.7 애플리케이션 테스트 흐름
- 애플리케이션은 깃허브를 권한 부여 서버이자 리소스 서버로 이용
- 사용자가 로그인하려고 하면 클라이언트는 사용자를 깃허브 로그인 페이지로 리다이렉트함
- 사용자가 로그인하면 깃허브는 권한 부여를 제공하고 애플리케이션을 콜백
- 애플리케이션은 승인 코드를 기반으로 액세스 토큰을 요청
- 이제 애플리케이션은 액세스 토큰을 제공하고 리소스 서버에서 사용자 세부 정보에 접근할 수 있음
- 리소스 서버의 응답에는 메인 페이지의 URL과 함께 사용자 세부 정보가 포함됨
참고
스프링 시큐리티 인 액션
반응형
'Spring > 스프링 시큐리티 인 액션' 카테고리의 다른 글
| [14장] OAuth 2: 리소스 서버 구현 (0) | 2025.06.01 |
|---|---|
| [13장] OAuth 2: 권한 부여 서버 구현 (0) | 2025.06.01 |
| [10장] CSRF 보호와 CORS 적용 (0) | 2025.05.31 |
| [8장] 권한 부여 구성: 제한 적용 (0) | 2025.05.30 |
| [7장] 권한 부여 구성: 액세스 제한 (0) | 2025.05.30 |