이번주 두번째 위클리페이퍼
- OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명하세요.
OAuth 2.0
비밀번호 같은 자격 증명을 제3의 애플리케이션에 노출하지 않은 채, 특정 서비스의 리소스(프로필 정보, 사진첩 등등..)에 대한 접근권한을 안전하게 위임하기 위한 업계 표준 권한부여 프레임워크
보통 API에서 자주 사용한다
OAuth 2.0의 주요 컴포넌트
1. 리소스 소유자(Resource Owner) :
보호된 리소스(데이터)의 주인인 최종 사용자
가령, Google 계정이나 Naver 계정을 소유한 사용자를 일컫는다
2. 클라이언트(Client) :
리소스 소유자를 대신하여 보호된 리소스에 접근을 요청하는 제3자 애플리케이션
Google캘린더 일정을 연동하는 캘린더 앱이나, Google Docs로 작성한 문서들을 연동하는 앱 등등..
3. 권한 서버(Authorization Server) :
리소스 소유자를 인증하고, 클라이언트에게 접근 토큰(Access Token)을 발급해주는 서버
다른 웹 브라우저에서 인증할 때 Google인증을 통해 로그인을 할 수 있는 시스템
4. 리소스 서버(Resource Server) :
보호된 리소스를 호스팅하는 서버. 클라이언트로부터 접근 토큰을 받아 유효성을 검증한 후, 요청된 리소스를 제공함
사용자의 캘린더 데이터, 프로필 정보를 실제로 저장하고 있는 Google API 서버 등..
Authorization Code Grant(권한 부여 승인 코드)의 의미, 흐름
Authorization Code Grant
- OAuth 2.0에서 가장 표준적이고 안전한 권한 부여 방식.
서버 사이드 애플리케이션(웹 애플리케이션)에서 사용된다
- 클라이언트가 접근 토큰을 직접 받지 않고,
중간 단계에서 임시 승인 코드(Authorization Code)를 발급받아 보안을 강화하는 방식 **
권한 부여 승인 코드의 흐름
1. 권한 부여 요청
- 사용자(브라우저)가 사용자의 앱(클라이언트)에서 'Google 캘린더로 로그인'을 클릭함
- 클라이언트는 사용자의 브라우저를 Google(권한 서버)의 로그인 페이지로 리디렉션 시킨다.
이 때, URL에는 중요한 정보들이 쿼리 파라미터에 포함된다
1) response_type=code : 권한 부여 승인 코드를 요청한다는 의미임
2) client_id : 클라이언트가 사전에 Google에 등록하고 발급받은 고유 식별자를 의미함
3) redirect_url : 권한을 부여한 후 Google이 사용자를 다시 돌려보낼 클라이언트의 주소를 의미함
4) scope : 클라이언트가 요청하는 권한의 범위를 의미함
5) state : CSRF 공격을 방지하기 위해 클라이언트가 생성하는 임의의 문자열을 의미함
2. 사용자 인증 및 동의
- 사용자가 Google 로그인 페이지에서 ID, 비밀번호를 입력해서 본인을 인증한다(Google ID, PW)
- 인증이 완료되면 서버는 앱이 요청한 권한 목록을 보여주며, 사용자에게 이 권한을 허용할 것인지에 대한 화면 제시
3. 승인 코드 발급(Authorization Code Grant)
- 사용자가 OK! 버튼을 누른다
- 권한 서버(Google)는 미리 지정된 redirect_url로 사용자의 브라우저를 다시 돌려보낸다.
이 때 URL에는 임시 승인 코드(Authorization Code)와 이전에 받은 state값이 포함된다.
4. 접근 토큰 요청
- 클라이언트의 백엔드 서버는 받은 승인코드를 활용해서 권한 서버의 토큰 엔드포인트(Token Endpoint)로 직접 요청을 보냄.
이 요청은 사용자의 브라우저를 거치지 않는 서버간 통신(Back-Channel)으로 이루어지므로 보안에 용이하며, 이하의 내용이 포함된다
1) grant_type=authorization_code : 승인 코드를 사용해서 토큰을 요청한다는 의미
2) code : 승인 코드 발급을 통해 발급받은 임시 승인 코드
3) redirect_url : 권한 부여 요청에서 보낸 redirect_url과 동일한 값(보안 검증용)
4) client_id, client_secret : 클라이언트의 자격 증명 정보
5. 접근 토큰 발급
- 권한 서버는 전달받은 client_id, client_secret 등을 모두 검증하고 이 정보들이 유효하다면, 접근 토큰(갱신 토큰도 필요하면 함께 발급해줌)을 클라이언트에게 발급해준다
* 갱신 토큰(Refresh Token) : 접근 토큰이 만료되었을 때, 사용자의 재인증 없이 새로운 접근 토큰을 요청하는 데 사용하는 토큰
6. 리소스 접근
- 클라이언트는 발급받은 접근 토큰을 HTTP 요청의 Authorization 헤더에 담아서 Google API 서버(리소스 서버)에 보낸다
- 리소스 서버는 해당 접근 토큰이 유효한지 확인하고, 유효하다면 클라이언트가 요청한 리소스(가령, 사용자의 캘린더 일정)를 응답으로 제공해준다.
'위클리페이퍼' 카테고리의 다른 글
| @Cacheable, @CachePut, @CacheEvict에 대해서 (0) | 2025.10.20 |
|---|---|
| 경쟁 상태(Race Condition)에 대해서 (0) | 2025.10.14 |
| 세션 기반 인증과 토큰 기반 인증, 보안 고려사항 (0) | 2025.09.22 |
| AWS RDS의 장단점, EC2와의 차별점에 대해 (0) | 2025.08.26 |
| Docker, 컨테이너에 대해서 (0) | 2025.08.19 |