[Spring Security] OAuth2 인증
위 사이트는 카카오, 구글과 아무런 상관이 없는 별도의 서비스인데 어떻게 카카오와 구글 계정으로 로그인을 할 수 있는 걸까요?
최근 들어 많은 서비스가 구글, 카카오, 네이버 등의 계정을 통해 더욱 쉽게 회원가입과 로그인을 할 수 있도록 제공하고 있으며, 서비스에 따라 회원 관리뿐만 아니라 다른 SNS에 게시글을 게시하도록 하거나 회원 정보를 연동하기도 합니다.
일반적으로 웹에서 제공되는 서비스의 경우, 사용자가 해당 서비스를 이용하기 위해서는 회원가입과 로그인 인증을 통해 서비스를 이용할 권한을 부여받는 절차가 필요하고, 민감한 정보를 제공하는 서비스의 경우 인증을 위한 절차가 까다로운 것이 사실입니다.
하지만 구글이나 카카오, 네이버 등의 신뢰할 만한 벤더를 통해 사용자의 인증이 처리됨으로써 사용자의 편의성은 향상되었습니다.
이처럼 사용자가 특정 서비스를 이용하기 위해 신뢰할 만한 벤더에게 대신 인증 처리를 위임하는 방식이 바로 OAuth 2 인증 방식입니다.
이번 유닛에서는 OAuth 2가 무엇인지, OAuth 2의 인증 처리 흐름은 어떻게 구성되는지 자세히 살펴보고 Spring Security에서 OAuth 2를 어떻게 구현할 수 있는지 학습하도록 하겠습니다.
[Spring Security] OAuth 2 적용을 위한 사전 준비 사항
이번 유닛의 학습을 원활하게 진행하기 위해 Spring Security 그리고 OAuth 2와 관련된 의존 라이브러리를 제외한 구성 요소(Controller, Service, Repository 등)들이 포함된 템플릿 프로젝트를 사용하도록 하겠습니다.
데이터 액세스 계층은 Spring Data JPA의 Repository로 구성이 되어 있습니다.
- 템플릿 프로젝트 복제
- 아래 github 링크에서 실습용 repository를 clone합니다.
- IntelliJ IDE로 clone 받은 local repository 디렉토리의 프로젝트를 Open합니다.
- 학습을 진행하며 학습 내용에 따라 예제 코드를 타이핑해 봅니다.
[Spring Security] OAuth 2 적용을 위한 참고용 레퍼런스 코드
이번 유닛에서 학습한 예제 코드는 아래 github에서 확인할 수 있습니다.
챕터에서 사용한 예제 코드는 챕터에 있는 코드들을 직접 타이핑해본 후, 학습 내용을 조금 더 구체적으로 이해하기 위한 용도로만 활용해 주세요.
- OAuth 2 적용에 사용한 예제 코드
학습 목표
- OAuth 2의 인증 방식을 설명할 수 있다.
- Authorization Code와 Access Token의 차이에 대해 이해할 수 있다.
- Authorization Server와 Resource Server의 차이에 대해 이해할 수 있다.
- Spring Security 기반의 애플리케이션에 OAuth 2를 적용할 수 있다.
Chapter - OAuth2란?
이번 챕터에서는 OAuth 2의 개념을 이해하고 OAuth 2를 이용해 사용자의 인증을 처리하는 방식을 알아보도록 하겠습니다.
여러분들이 이전 유닛까지 학습했던 로그인 인증 방식은 사용자의 크리덴셜(Credential)을 직접 관리하는 방식입니다.
즉, 회원 정보 중에서 로그인 인증에 사용되는 Password를 백엔드 애플리케이션 쪽에서 직접 관리하는 구조입니다.
하지만 OAuth 2를 통한 인증은 로그인 인증 정보를 백엔드 애플리케이션에서 직접적으로 관리하지 않습니다.
OAuth 2는 어떤 방식으로 사용자의 인증을 처리하길래 사용자의 인증 정보를 백엔드 애플리케이션 쪽에서 관리하지 않아도 되는지 OAuth 2의 인증 처리 흐름을 통해 자세히 살펴보도록 하겠습니다.
학습 목표
- OAuth 2가 무엇인지 이해할 수 있다.
- OAuth 2의 인증 방식에 대해 설명할 수 있다.
- Authorization 서버와 Resource 서버의 차이에 대해 이해할 수 있다.
OAuth2 란?
앞에서의 예시와 같이 여러분들이 웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2라는 기술을 바탕으로 구현됩니다.
OAuth 2란 무엇일까요?
전통적으로 특정 애플리케이션의 서비스를 이용하는 사용자에 대한 인증 처리는 해당 서비스를 직접적으로 제공하는 애플리케이션에서 담당해 왔습니다.
인증 서버를 별도로 분리해서 인증을 처리하든 하나의 서버에서 사용자의 인증도 처리하고 그와 동시에 애플리케이션의 서비스도 함께 제공하든 어쨌든 서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜(Credential)을 직접적으로 관리하는 것이 일반적입니다.
예를 들어 사용자에 대한 일정 관리 서비스를 제공하는 애플리케이션이 있다고 가정하겠습니다. 이 일정 관리 서비스는 특별히 외부의 써드 파티 애플리케이션과의 통신 없이 자체적으로 회원의 크리덴셜(Credential)을 관리하는 단순한 애플리케이션입니다.
이 경우 [그림 4-29]와 같이 자신의 백엔드 애플리케이션에서 회원의 크리덴셜(Credential)을 관리합니다.
[그림 4-29] 전통적인 애플리케이션에서 사용자의 크리덴셜을 저장하는 아키텍처
그런데 OAuth 2는 [그림 4-29]와 같은 전통적인 인증 처리 방식과 조금 다른 처리 방식으로 동작합니다.
예를 하나 더 들어보겠습니다.
앞에서 언급한 사용자의 일정 관리 서비스를 제공하는 애플리케이션에서 사용자에게 캘린더 형태의 서비스를 제공하기 위해 Google의 Calendar API를 이용하는 기능이 추가되었다고 가정하겠습니다.
이 경우, 아래의 [그림 4-30]과 같이 일정 관리 서비스에 대한 회원 가입을 통해 사용자의 크리덴셜(Credential)을 관리해야 함은 물론이고, Google의 Calender API를 이용하기 위해 Google에서 사용하는 사용자의 크리덴셜(Credential)까지 일정 관리 서비스와 공유해야 합니다.
[그림 4-30] 써드 파티 API를 사용을 위해 써드 파티 애플리케이션의 크리덴셜을 저장하는 아키텍처
이렇게 되면 어떤 문제점이 발생할까요?
사용자가 일정 관리 서비스에 대한 회원 가입을 하는 시점 또는 캘린더 서비스를 사용하는 시점에 Google Calendar API를 이용하기 위해 Google에서 사용하는 사용자의 크리덴셜(Credential)을 일정 관리 서비스 애플리케이션에 추가적으로 제공해야 합니다. 그리고 제공한 Google에 대한 크리덴셜(Credential)은 일정 관리 서비스 애플리케이션 어딘가에 저장될 테고요.
- 우선 사용자에게 가장 중요한 정보인 크리덴셜(Credential)이 두 개나 관리돼야 합니다.
- Google 사이트에서 패스워드를 변경하더라도 변경된 Google의 패스워드를 일정 관리 서비스 애플리케이션에서 추가로 업데이트해 주어야 합니다.
- 일정 관리 애플리케이션이 Google 사이트에서 사용하는 크리덴셜(Credential)을 직접적으로 가지고 있는 것도 보안상 심각한 문제입니다. 한마디로 보안 침해 사고라도 발생한다면 심각한 피해가 발생하기 딱 좋은 상황인 것입니다.
이런 문제점을 보완하는 효과적인 방법 중 하나는 Google에서 사용하는 사용자의 크리덴셜을 일정 관리 서비스 애플리케이션에서 직접적으로 관리하지 않으면서도 Google Calendar API를 이용할 수 있게 하는 것입니다.
이런 방식으로 동작하는 애플리케이션을 구현하는 것이 가능할까요?
바로 OAuth 2 인증 프로토콜을 사용하면 가능합니다.
OAuth 2는 특정 애플리케이션(Client)에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해 주고 Resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식입니다.
즉, 앞에서 언급한 일정 관리 서비스 애플리케이션을 예로 들어 OAuth 2 인증 프로토콜에 대한 개념을 간단히 정리하자면, 아래의 [그림 4-31]과 같이 일정 관리 서비스 애플리케이션을 사용하는 사용자의 Google 전용 크리덴셜(Credential)이 일정 관리 서비스 애플리케이션에 직접적으로 제공되지 않아도 됩니다.
로그인 자체는 구글 로그인 인증을 이용하고, 구글 로그인에 성공하면 Access Token을 전달받아서 Google Calendar API를 사용하기 위해 Access Token을 이용합니다.
[그림 4-31] 써드 파티 애플리케이션의 크리덴셜을 저장하지 않는 아키텍처
일정 관리 서비스 애플리케이션에 구글의 크리덴셜(Credential)이 직접적으로 제공되지 않기 때문에 일정 관리 서비스 애플리케이션에서 사용하는 크리덴셜(Credential) 저장소에 저장될 필요가 없으므로 사용자의 크리덴셜(Credential)을 이중으로 관리하지 않아도 됩니다.
관리하는 크리덴셜(Credential)이 줄어든다는 것은 그만큼 보안성도 향상된다는 의미와 같습니다.
그렇다면 OAuth 2는 어떤 유형의 애플리케이션에서 주로 사용할 수 있을까요?
OAuth 2를 사용하는 애플리케이션 유형
1️⃣ 써드 파티 애플리케이션에서 제공하는 API의 직접적인 사용
첫 번째로 Google, Github, Facebook 같은 신뢰할만한 써드 파티 애플리케이션에서 제공하는 API를 직접적으로 사용하는 애플리케이션을 구현하는데 OAuth 2를 사용할 수 있습니다.
사용자가 OAuth 2 인증 프로토콜을 이용해 써드 파티 애플리케이션에 대한 인증에 성공하면 써드 파티 애플리케이션에서 제공하는 API를 활용한 커스텀 서비스를 제공하는 것입니다.
2️⃣ 추가적인 인증 서비스 제공 용도
두 번째는 써드 파티 애플리케이션의 서비스를 이용하는 것뿐만 아니라 추가적인 인증 서비스를 제공하기 위한 용도로 사용하기 위함입니다.
쉽게 말해서 일반적으로 제공하는 아이디/패스워드 로그인 인증 이외에 OAuth 2를 이용한 로그인 인증 방법을 추가적으로 제공하는 것입니다.
만약 특정 서비스를 제공하는 애플리케이션에서 사용자의 크리덴셜(Credential)을 남기고 싶지 않을 경우 OAuth 2 로그인 인증 방법으로 로그인하면 됩니다.
앞에서 언급한 OAuth 2를 사용하는 애플리케이션 유형이 지금은 머릿속에 그려지지 않겠지만 이어지는 챕터에서 설명하는 OAuth 2 인증 아키텍처의 구성요소와 OAuth 2의 동작 방식 등을 학습하고 나면 OAuth 2 기반의 애플리케이션에 대해 조금 더 구체적으로 이해할 수 있을 거라 생각합니다.
핵심 포인트
- OAuth 2는 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해 주고 접근 권한에 대한 토큰을 발급한 뒤 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식이다.
- OAuth 2를 사용하는 애플리케이션 유형
- 써드 파티 애플리케이션에서 제공하는 API를 직접적으로 사용
- 추가적인 인증 서비스를 제공하기 위한 용도
심화 학습
- OAuth 2에 대해서 조금 더 알아보고 싶다면 아래 링크를 참고하세요.
OAuth2의 동작 방식
이전 챕터에서 OAuth 2가 무엇인지 살펴보면서 OAuth 2의 개념을 이해하기 위해 OAuth 2의 단순한 아키텍처를 확인해 보았는데, OAuth 2의 동작 방식은 앞에서 보았던 아키텍처보다는 조금 더 복잡한 흐름으로 구성됩니다.
그렇다고 우리가 이해하기 어려울 정도로 난해하지는 않으니 지금부터 차근차근 하나씩 살펴보도록 하겠습니다.
OAuth 2 인증 컴포넌트(Component, 구성요소)들의 역할
OAuth 2 인증 프로토콜의 흐름을 이해하기 위해서는 OAuth 2 인증을 처리하는 컴포넌트에는 어떤 것이 있고, 각각의 컴포넌트들이 어떤 역할을 하는지 이해하는 것이 중요합니다.
- Resource Owner
- Resource Owner는 사용하고자 하는 Resource의 소유자를 말합니다.⭐ Resource Owner는 한마디로 Google 등의 서비스를 이용하는 사용자입니다.
- 💡 Bob이라는 사용자가 구글 계정으로 로그인해서 Google의 서비스(Resource)를 이용하고 있다면 Bob이 Google 서비스라는 Resource에 대한 Resource Owner가 됩니다.
- Client
- Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션입니다.💡 Bob이라는 사용자가 A라는 애플리케이션을 통해서 Google의 소셜 로그인을 이용한다면 애플리케이션 A가 Client가 됩니다.⭐ 항상 Client와 Server에 대한 기준을 잡기 위해서는 서비스를 제공하는 쪽을 기준으로 생각해야 합니다.Client와 Server의 관계가 여전히 헷갈린다면 SpringMVC Rest Client 챕터를 다시 확인하기 바랍니다.
- 우리가 Spring MVC 섹션에서 만들어 보았던 커피 주문 샘플 애플리케이션이 외부의 API 서비스를 이용한다면 외부 API를 이용하는 측면에서는 커피 주문 샘플 애플리케이션이 Client인 것입니다.
- Client라는 용어가 조금 헷갈릴 수 있는데, ‘어떤 서비스를 이용하고자 하는 쪽은 Client이다’라고 생각하면 될 것 같습니다.
- Client는 서버, 데스크톱, 모바일 또는 기타 장치에서 실행되는 애플리케이션이 될 수 있습니다.
- Resource Server
- OAuth 2 인증 처리 흐름 상에서의 Resource Server는 Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버입니다.
- 💡 A라는 애플리케이션(Client)이 Google Photo에서 Bob이라는 Resource Owner의 사진(Resource)을 가져오는 경우, Google Photo 서비스를 제공하는 애플리케이션이 Resource Server가 됩니다.
- Authorization Server
- OAuth 2 인증 처리 흐름에서 Authorization Server는 Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버입니다.💡 Bob이라는 사용자(Resource Owner)가 구글 로그인 인증에 성공하면 A라는 애플리케이션(Client)이 Authorization Server로부터 Google Photo에 저장되어 있는 Bob의 사진(Resource)에 접근할 수 있는 권한(Access Token)을 부여받습니다.
- Resource Owner가 인증에 성공하면 Authorization Server는 Client에게 Access Token 형태로 Resource Owner의 Resource에 접근할 수 있는 권한을 부여합니다.
그렇다면 이번에는 앞에서 살펴본 OAuth 2 인증 컴포넌트들이 어떤 식으로 상호 작용하면서 사용자의 인증을 처리하는지 그림으로 확인해 보도록 하겠습니다.
[그림 4-32] OAuth 2 컴포넌트 간의 상호 작용을 통한 인증 처리 흐름
[그림 4-32]는 OAuth 2를 구성하는 컴포넌트 간의 상호 작용을 통한 인증 처리 흐름입니다.
인증 처리를 위한 세부적인 단계가 조금 생략된 상태이긴 하지만 대략적인 OAuth 2의 인증 처리 흐름을 이해하기에는 충분합니다. [그림 4-32]에 대한 설명은 다음과 같습니다.
(1) Resource Owner는 Client 역할을 하는 웹 애플리케이션에게 OAuth2 인증을 요청합니다. 여기에서 인증 요청은 Resource Owner가 인증을 할 수 있도록 Client인 웹 애플리케이션이 자체적으로 로그인 화면을 제공하는 것이 아닙니다. ⭐ Resource Owner는 자신의 계정 정보를 관리하고 있는 써드 파티 애플리케이션에 로그인하길 원하는 것이며, 이 요청을 Client인 웹 애플리케이션에 전송하는 것입니다.
(2) Client는 Resource Owner가 Resource Owner의 계정 정보를 관리하고 있는 써드 파티 애플리케이션에 로그인할 수 있도록 **써드 파티 애플리케이션의 로그인 페이지로 리다이렉트(Redirect)**합니다.
(3) Resource Owner는 로그인 인증을 진행하고 로그인 인증에 성공하면,
(4) ⭐ Authorization Server가 Resource Owner의 로그인 인증이 성공적으로 수행되었음을 증명하는 Access Token을 Client에게 전송합니다. ⭐⭐ Resource Owner에게 Access Token을 전송하는 것이 아니라 Client 애플리케이션에게 전송하는 것이라는 걸 꼭 기억하세요. Client는 Resource Owner를 대신해서 Resource Owner의 Resource를 사용하는 대리인 역할을 하기 때문입니다. ^^
(5) Access Token을 전달받은 Client는 이제 Resource Owner의 대리인 역할을 수행할 수 있게 되었으므로, Resource Server에게 Resource Owner 소유의 Resource를 요청합니다.
(6) Resource Server는 Client가 전송한 Access Token을 검증해서 Client가 Resource Owner의 대리인으로서의 자격이 증명되면 Resource Owner의 Resource를 Client에게 전송합니다.
조금은 복잡해 보이는 인증 처리 흐름이라고 느낄 수 있겠지만 핵심은 ⭐ 어떤 Resource를 소유하고 있는 Resource Owner를 대신하는 누군가(Client)가 Resource Owner의 대리인 역할을 수행한다는 것입니다.
우리가 이전 챕터에서 예로 들었던 일정 관리 애플리케이션이 Google의 Calendar API를 이용해 사용자에게 Calendar 서비스를 제공하는 흐름을 OAuth 2 인증 컴포넌트로 표현하면 아래의 [그림 4-33]과 같습니다.
[그림 4-33] Google 서비스를 이용하는 사용자의 대리인 역할을 하는 일정 관리 애플리케이션
[그림 4-33]은 [그림 4-32]와 별반 차이가 없습니다.
[그림 4-32]가 OAuth 2의 컴포넌트를 일반화해서 설명한 그림이라면 [그림 4-33]은 Google이라는 구체적인 써드 파티 애플리케이션을 예로 든 그림입니다.
여러분들의 이해를 돕기 위해 Google 네트워크의 영역에 있는 부분은 Google의 로고를 빨간색 박스로 표시해 두었습니다.
OAuth 2 인증 프로토콜에서 사용되는 용어
- Authorization Grant
- Authorization Grant는 Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜(Credential)을 의미합니다.
- 한마디로 Client가 Access Token을 얻기 위한 수단이라고 생각하면 되며 아래의 네 가지 Authorization Grant 타입이 있습니다. (Authorization Grant 타입에 대한 자세한 내용은 잠시 뒤 살펴보겠습니다.)
- Authorization Code
- Implicit Grant Type
- Client Credentials
- Resource Owner Password Credentials
- Access Token
- Access Token은 Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위해 사용하는 자격 증명용 토큰입니다.
- Authorization Code와 Client Secret을 이용해 Authorization Server로부터 전달받은 Access Token으로 자격을 증명하면 Resource Server에 접근할 수 있습니다.
- Scope
- Scope는 주어진 액세스 토큰을 사용하여 액세스할 수 있는 Resource의 범위를 의미합니다.
- 예를 들어 Scope 설정을 통해 해당 Resource Owner의 사진첩에는 접근할 수 있지만, 연락처 등 다른 Resource에는 접근할 수 없도록 접근 권한을 지정할 수도 있습니다.
Authorization Grant 유형
1️⃣ Authorization Code Grant : 권한 부여 승인 코드 방식
- Authorization Code Grant는 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로, 가장 많이 쓰이고 기본이 되는 방식입니다.
- Authorization Code Grant 방식에서는 Refresh Token을 사용할 수 있습니다.
- 권한 부여 승인 요청 시 응답 타입(response_type)을 code로 지정하여 요청합니다.
[그림 4-34] Authorization Code Grant 방식의 인증 처리 흐름
- Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송합니다.
- Client는 Authorization Server에 Authorization Code를 요청합니다. 이때 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송합니다.
- Resource Owner는 로그인 페이지를 통해 로그인을 진행합니다.
- 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에게 전달합니다. (이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달합니다.)
- Client는 전달받은 Authorization Code를 이용해 Access Token 발급을 요청합니다. Access Token을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorization Code를 함께 전송합니다.
- 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급합니다.
- Client는 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청합니다.
- Access Token을 확인한 후 요청받은 Resource를 Client에게 전달합니다.
2️⃣ Implicit Grant : 암묵적 승인 방식
- 별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식입니다.Refresh Token 사용이 불가능하며, 이 방식에서 Authorization Server는 Client Secret을 통해 클라이언트 인증 과정을 생략합니다.
- 이는 자격증명을 안전하게 저장하기 힘든 Client(자바스크립트 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식입니다.
- 권한 부여 승인 요청 시 응답 타입(response_type)을 token으로 지정하여 요청합니다.
[그림 4-35] Implicit Grant 방식의 인증 처리 흐름
- Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송합니다.
- Client는 Authorization Server에게 접근 권한 요청을 합니다.
- 요청과 함께 미리 생성한 Client ID, Redirect URI, 응답 타입을 전송합니다. (⭐ Authorization Code를 획득하기 위한 요청이 아닙니다)
- Resource Owner는 로그인 페이지를 통해 로그인을 진행합니다.
- 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달합니다.
- Client는 Access Token을 이용해 Resource Server에게 Resource를 요청합니다.
- Access Token을 확인한 후 요청받은 Resource를 전달합니다.
3️⃣ Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식
- 간단하게 로그인 시 필요한 정보(username, password)로 Access Token을 발급받는 방식입니다. 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로, Refresh Token의 사용도 가능합니다.
- 예를 들어 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인, 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우가 Resource Owner Password Credential Grant에 해당합니다.
- 다시 말해 Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용이 가능합니다.
[그림 4-36] Resource Owner Password Credential Grant 방식의 인증 처리 흐름
- Resource Owner는 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송합니다. 이때 로그인에 필요한 정보(Username, Password)를 이용해 요청합니다.
- Client에서는 Resource Owner에게서 전달받은 로그인 정보를 통해 Authorization Server에 Access Token을 요청합니다. 미리 생성한 Client ID, 권한 부여 방식, 로그인 정보를 함께 전달합니다.
- 요청과 함께 온 정보들을 확인한 후 Client에게 Access Token을 전달합니다.
- Client는 Access Token을 이용하여 Resource Server에게 Resource를 요청합니다.
- Access Token을 확인한 후 요청받은 Resource를 전달합니다.
4️⃣ Client Credentials Grant : 클라이언트 자격 증명 승인 방식
- Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용할 수 있는 방식입니다.
- 이 방식은 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야 하며, Refresh Token의 사용은 불가능합니다.
[그림 4-37] Client Credentials Grant 방식의 인증 처리 흐름
핵심 포인트
- OAuth 2 인증 컴포넌트
- Resource Owner는 사용하고자 하는 Resource의 소유자를 의미한다.
- Client는 Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션을 의미한다.
- Resource Server는 Client의 요청을 수락하고 Resource Owner에 해당하는 Resource를 제공하는 서버를 의미한다.
- Authorization Server는 Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버를 의미한다.
- OAuth 2 인증 프로토콜의 키포인트는 어떤 Resource를 소유하고 있는 Resource Owner를 대신하는 누군가(Client)가 Resource Owner의 대리인 역할을 수행한다는 것이다.
- Authorization Grant에 따른 인증 처리 방식
- Authorization Code Grant : 권한 부여 승인 코드 방식
- Implicit Grant : 암묵적 승인 방식
- Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식
- Client Credentials Grant : 클라이언트 자격 증명 승인 방식
심화 학습
- OAuth 2 인증 컴포넌트에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
- Authorization Grant에 따른 인증 처리 방식에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
