OAuth의 최종 목적은 Access Token을 발급받는 것입니다. 그리고 발급받은 Access Token을 사용해서 리소스 서버에 존재하는 리소스를 엑세스 할 수 있습니다. 이러한 OAuth의 인증 절차와 인증 종류에 대해 조금 더 알아보겠습니다.
OAuth 2.0의 인증 절차
(A) 클라이언트가 리소스 소유자에게 권한 부여를 요청합니다. 인증 요청은 리소스 소유자에게 직접(표시된 대로) 또는 바람직하게는 중개자로서 인증 서버를 통해 간접적으로 이루어질 수 있습니다.
(B) 클라이언트는 자원 소유자의 권한을 나타내는 크리덴셜인 권한 부여를 수신하며, 본 명세서에서 정의한 4가지 권한 부여 유형 중 하나 또는 확장 권한 부여 유형을 사용하여 표현한다. 권한 부여 유형은 권한 부여를 요청하기 위해 클라이언트가 사용하는 방법과 권한 부여 서버에서 지원하는 유형에 따라 다릅니다.
(C) 클라이언트는 Authorization Server로 인증하고 Authorization Grant를 제시하여 액세스 토큰을 요청합니다.
(D) Authorization Server는 클라이언트를 인증하고 Authorization Grant의 유효성을 검사하고 유효하면 액세스 토큰을 발급합니다.
(E) 클라이언트는 리소스 서버에 보호된 리소스를 요청하고 액세스 토큰을 제시하여 인증합니다.
(F) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 요청을 처리합니다.
OAuth 2.0의 네 가지 역할
리소스 소유자 (Resource Owner)
보호된 리소스에 대한 액세스 권한을 부여할 수 있는 엔터티입니다. 리소스 소유자가 개인인 경우 최종 사용자라고 합니다.
클라이언트 (Client)
리소스 소유자를 대신하여 권한 부여를 통해 보호된 리소스를 요청하는 애플리케이션입니다. "클라이언트"라는 용어는 특정 구현 특성(예: 응용 프로그램이 서버, 데스크톱 또는 기타 장치에서 실행되는지 여부)을 의미하지 않습니다.
인증 서버 (Authorization Server)
리소스 소유자를 성공적으로 인증하고 권한을 얻은 후 서버가 클라이언트에 액세스 토큰을 발급합니다.
리소스 서버 (Resource Server)
액세스 토큰을 사용하여 보호된 리소스 요청을 수락하고 응답할 수 있는 보호된 리소스를 호스팅 하는 서버입니다.
[참고] 인증 서버와 리소스 서버 간의 상호 작용은 RFC 6749에서 정의하지 않습니다. Authorization Server는 Resource Server와 동일한 서버이거나 별도의 엔터티일 수 있습니다. 또한 단일 Authorization Server는 여러 Resource Server에서 허용하는 액세스 토큰을 발급할 수 있습니다.
OAuth 2.0의 네 가지 Grant Type
Access Token을 받기 위해 사용되는 인증 타입은 아래와 같습니다.
- 인증 코드 (Authorization code) – 서버 측 및 모바일 웹 애플리케이션에 주로 사용되는 가장 일반적인 흐름입니다.
- 암시적 (Implicit) – 이 흐름에서는 클라이언트가 액세스 토큰을 직접 검색해야 합니다.
- 리소스 소유자 암호 (Resource owner password) – 사용자 이름과 암호를 사용하여 로그인해야 합니다.
- 클라이언트 자격 증명 (Client Credentials) – 서버 간 인증을 위한 이 흐름은 클라이언트 응용 프로그램이 개별 사용자를 대신하지 않고 자체적으로 작동하는 접근 방식을 설명합니다.
추가로 OAuth는 인증 서버와 상호 작용할 때 클라이언트가 사용할 추가 인증 메커니즘의 정의를 허용합니다.
JWT를 이용한 추가 인증 메커니즘 (RFC 7523)
RFC 7523 - JWT 인증 방식의 특징, OAuth 2.0과의 관계
RFC 7523 - JWT 인증 방식의 특징, OAuth 2.0과의 관계
JWT Authorization Grant (RFC 7523) RFC 7523은 OAuth 프레임워크 기반에서 작동하는 JWT인증 방식이며, 기본적으로 OAuth의 플로우를 그대로 사용하지만, 인증을 받기 위한 수단이 JWT 인 것으로 이해할 수 있습
jsonm.tistory.com
OAuth 인증 이후 절차
OAuth 인증 절차를 통해 Access Token을 받았다면, 실제 API를 사용할 수 있게 되는데 아래와 같은 순서로 진행됩니다.
- HTTP 헤더에 발급받은 Access Token을 추가한다.
- Access Token이 포함된 API를 서버로 요청을 한다.
- 서버는 토큰이 유효한 경우 리소스를 내려준다.
[참고] Access Token 갱신 (Refreshing an Expired Access Token)
Access Token은 짧은 수명주기를 가지게 되며, Access Token이 만료되면 Access Token 발급 당시 함께 발급받은 Refresh Token을 통해 Access Token을 리뉴얼 할 수 있습니다. 이 방식을 사용하면 Access Token 갱신 시 다시 인증을 받을 필요가 없어지게 됩니다.
[참고] Authentication과 Authorization 차이
Authentication과 Authorization 차이
인증 (Authentication) 인증(Authentication)은 서버 입장에서 내가 누구인지 확인하는 과정이며, 올바른 신원을 증명하는 것을 의미한다. HTTP에서 주로 사용되는 인증(Authentication) 방법 기본 인증 (Basic Aut
jsonm.tistory.com
'IT 지식' 카테고리의 다른 글
| 개발자 포털(Developer Portal) 구축 방안 (10) | 2023.06.15 |
|---|---|
| Web API의 특징과 장단점 (0) | 2023.06.12 |
| Authentication과 Authorization 차이 (0) | 2023.06.11 |
| JWT (JSON Web Token)의 구조와 사용 예 (0) | 2023.06.11 |
| RFC 7523 - JWT 인증 방식의 특징, OAuth 2.0과의 관계 (0) | 2023.06.02 |