OAuth 2.0 개념과 동작 원리 그리고 권한부여 유형

DaeHoon·2023년 10월 29일

OAuth 사용 이전

유저 입장: 구글 계정을 우아한 아이디가 관리하고 있어 해당 서비스를 믿을 수 없음. (해킹 위험?)
우아한 캘린더 입장: 유저의 구글 아이디와 패스워드를 관리하는 것 자체가 부담
구글 입장: 외부에서 ID, PW가 노출될 수 있다는 리스크

전부 서비스가 구글의 아이디와 패스워드를 직접 관리하기 때문에 발생하는 일

OAuth 사용 이후

유저는 구글에 직접 아이디를 입력해 인증 과정 수행
구글에서 인증이 유효하다고 확인되면, 유저의 캘린더에 접근할 수 있는 권한을 서비스에 부여
서비스는 부여받은 권한으로 사용자 유저의 캘린더에 접근함

요약하자면 인증은 유저가 직접, 권한은 서비스에게

Grant

OAuth 2.0에서 여러가지 환경에 대한 플로우를 나타내는 인증 방식
OAuth 2.0 프레임워크의 핵심은 다양한 클라이언트 환경에 적합한 인증 및 권한의 위임 방법(grant)을 제공하고 그 결과로 클라이언트에게 access_token을 발급하는 것이다.

Authorization Code (권한 부여 승인 코드 방식)

OAuth 2.0에서 가장 많이 사용되는 인증방식
권한 서버. 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행, Refresh Token 사용 가능 방식
주로 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용
권한 부여 승인 요청 시 response_type=code로 지정하여 요청하고, 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력함.
이 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은redirect_url로 Authorization Code를 전달하고, Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환된다.

Implicit (암묵적 승인 방식)

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식
Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않는다.
Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있다. (토큰 탈취 위험 증가)

권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력하게 되며 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달함.
주요 사용 사례
- 특별히 안전한 저장공간이 없는 Javascript SPA(Single Page Application)에 사용됨.

Resource Owner Password Credentials (자원 소유자 자격증명 승인 방식)

간단하게 username, password로 Access Token을 받는 방식
사용자의 ID와 비밀번호를 클라이언트에 직접 제공하게 되므로 다른 OAuth 플로우 (Grant) 보다 보안 위험이 크다.
클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안된다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식 Refresh Token 사용 가능
제공하는 API를 통해 username, password을 전달하여 Access Token을 받는다.
이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이여야 한다.
주요 사용 사례
- 신뢰된 클라이언트: 이 방식은 클라이언트가 리소스 소유자에게 완전히 신뢰될 때 사용. (ex 사용자의 디바이스에 설치된 개인용 모바일 앱)

Client Credentials (클라이언트 자격증명 승인 방식)

클라이언트의 자격증명만으로 Access Token을 획득하는 방식입니다. 즉 클라이언트 자체가 사용자의 대신으로 Access Token을 획득한다.
OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용된다.
주요 사용 사례
- 백엔드 서비스 간 통신: 두 서비스가 사용자의 개입 없이 서로 통신할 필요가 있을 때. 예: 마이크로서비스 간의 상호 작용.
- 제한된 리소스에 대한 액세스: 사용자와 관련이 없는 리소스에 대한 액세스가 필요할 때. 예: 공통 코드 또는 설정 정보 조회.
- 애플리케이션 수준의 권한: 특정 애플리케이션 또는 서비스에 권한을 부여할 때 사용자 개입이 필요 없는 경우.

Request and Response Examples

API Parameter	description	value
client_id, client_secret	클라이언트의 자격증명 클라이언트가 권한 서버에 등록하면 발급받을 수 있으며 권한 서버 연동 시 클라이언트 검증에 사용됨
redirect_url	권한 서버가 요청에 대한 응답을 보낼 url을 설정
response_type	권한 부여 동의 요청 시 포함되는 값으로 권한 부여 방식에 대한 설정	code: Authorization Code Grant, token: Implicit Grant
state	CSRF 공격에 대비하기 위해 클라이언트가 권한서버에 요청 시 포함하는 임의의 문자열. 필수 사항은 아니지만 클라이언트가 요청 시 state를 포함 시켰다면 권한 서버는 동일한 값을 클라이언트에게 보내야 함
grant_type	Access Token 획득 요청 시 포함되는 값으로 권한 부여 방식에 대한 설정	authorization_code: Authorization Code Grant, password: Resource Owner Password Credentials Grant, client_credentials: Client Credentials Grant
code	Authorization Code Grant 방식에서 Access Token요청 시 사용됩니다. 권한 서버에서 획득한 Authorization Code를 입력
token_type	발행된 Token의 타입. 대표적으로 Bearer, MAC(Message Authentication Code)가 있다.
expires_in	토큰 만료 시간 (단위: 초)
example_parameter	Token 타입에 따른 추가 파라미터

추가로 API 요청에 포함되는 Authorization Basic 헤더는 Client 자격증명 관련 데이터로 client_id와 client_secret값을 아래와 같이 Base64 인코딩하여 생성한다.

base64(client_id:client_secret)

Authorization Code Grant (권한 부여 승인 코드 방식)

# Step 1. Authorization
Request (GET)/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fc
Response: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

# Step 2. Access Token
Request (POST) /token
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

Response
{
           "access_token":"2YotnFZFEjr1zCsicMWpAA",
           "token_type":"example",
           "expires_in":3600,
           "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
           "example_parameter":"example_value"

}

Authorization Code 획득 후 해당 Code로 Access Token 획득

Implicit Grant (암묵적 승인 방식)

Request (GET)/authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Response http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

Authorize 요청 시 url로 Access Token이 바로 전달됨

Resource Owner Password Credentials (자원 소유자 자격증명 승인 방식)

Request (POST) /token
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w

Response 
{
           "access_token":"2YotnFZFEjr1zCsicMWpAA",
           "token_type":"example",
           "expires_in":3600,
           "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
           "example_parameter":"example_value"
}
 
Username, Password로 Access Token 획득

Client Credentials (클라이언트 자격증명 승인 방식)


Request (POST) /token
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials

Response
{
           "access_token":"2YotnFZFEjr1zCsicMWpAA",
           "token_type":"example",
           "expires_in":3600,
           "example_parameter":"example_value"

}

클라이언트 자격증명만으로 Access Token 획득

Reference

DaeHoon

평범한 백엔드 개발자

이전 포스트

Kotest에서 가독성 있는 테스트 코드 작성하기

다음 포스트

OAuth 2.0 개념과 동작 원리 그리고 권한부여 유형

OAuth 사용 이전

OAuth 사용 이후

Grant

Authorization Code (권한 부여 승인 코드 방식)

Implicit (암묵적 승인 방식)

Resource Owner Password Credentials (자원 소유자 자격증명 승인 방식)

Client Credentials (클라이언트 자격증명 승인 방식)

Request and Response Examples

Authorization Code Grant (권한 부여 승인 코드 방식)

Implicit Grant (암묵적 승인 방식)

Resource Owner Password Credentials (자원 소유자 자격증명 승인 방식)

Client Credentials (클라이언트 자격증명 승인 방식)

Reference

Kotest에서 가독성 있는 테스트 코드 작성하기

[마이크로서비스 패턴] 4. 트랜잭션 관리: 사가

0개의 댓글

관련 채용 정보