OAuth2 작동 방식

조승빈·2024년 10월 16일

Spring Security

목록 보기
10/11

OAuth2

OAuth2는 타사 웹사이트나 애플리케이션이 사용자의 리소스에 접근할 수 있도록 권한을 부여하는 프레임워크.

HTTP Basic 인증 방식의 문제

  • 모든 요청에 자격 증명을 보내야 한다.
    • 네트워크를 통해 자격 증명이 자주 공유된다.
    • 클라이언트가 자격 증명을 저장해 인증 및 권한 부여 요청과 함께 자격 증명을 서버에 보낼 수 있게 된다.
  • 사용자의 자격 증명을 별도의 시스템이 관리한다.

OAuth2는 리소스 서버, 사용자, 클라이언트, 권한 부여 서버로 이루어져 있다.

  • 리소스 서버: 사용자의 데이터를 실제로 저장하고 있는 서버이다. 예를 들어, 구글 드라이브에 저장된 파일이 리소스이다.
  • 클라이언트: 사용자가 이용하는 애플리케이션으로, 사용자의 자원에 접근하려고 한다. 예를 들어, 파일을 관리하는 서드파티 애플리케이션이 있을 수 있다.
  • 권한 부여 서버: 사용자의 인증을 관리하고, 클라이언트에게 액세스 토큰을 발급하는 서버이다. 구글의 OAuth 서버가 권한 부여 서버의 역할을 한다.

권한 부여는 토큰을 통해 이루어진다. access token과 비슷하다. 하지만 OAuth2는 그랜트(grant)라고 하는 토큰을 얻는 여러 방법을 제공하고 가장 일반적인 OAuth2 grant 유형은 다음과 같다.

  • 승인 코드
  • 암호
  • 갱신 토큰
  • 클라이언트 자격 증명

승인 코드 그랜트 유형

1단계: 승인 코드 그랜트 유형으로 인증 요청 수행
2단계: 승인 코드 그랜트 유형으로 액세스 토큰 얻기

인증 서버를 두번 호출하는 이유와 두 가지 다른 토큰(승인 코드와 액세스 토큰)이 필요한 이유

권한 부여 서버는 사용자가 직접 상호 작용했다는 증거로 첫 번째 코드를 생성. 클라이언트는 이 코드를 통해 자신의 자격 증명과 함께 액세스 토큰을 받기 위한 인증을 한다.
클라이언트는 이 두 번째 토큰을 이용해 리소스 서버의 리소스에 접근한다.

왜 한번에 둘 다 반환하지 않는 것인가?
권한 부여 서버가 곧바로 액세스 토큰을 반환하는 것을 암시적 그랜트 유형(implicit grant type)이라고 한다.
올바른 클라이언트에게 받았는지 확인하지 않은 액세스 토큰으로 리디렉션 URI를 호출하는 것이 덜 안전하기 때문이다.
첫 번째 단계에서 클라이언트는 승인 코드만을 받기 때문에, 이 단계에서는 아직 액세스 토큰을 발급하지 않아 클라이언트가 악의적인 공격에 노출되더라도 민감한 데이터에 접근하지 못하게 하는 보안 장치가 있다.

3단계: 승인 코드 그랜트 유형으로 보호된 리소스 호출

만약 승인 코드와 클라이언트 자격 증명이 모두 도난당할 경우
이 취약성을 완화하기 위해서는 PKCE 승인코드 그랜트 유형을 이용해 더 복잡한 시나리오에 의존해야 한다.
PKCE는 승인 코드 그랜트 유형의 보안성을 높이기 위해 사용되며, 특히 클라이언트 자격 증명이 공개적으로 노출될 수 있는 모바일 애플리케이션에서 많이 사용된다. PKCE는 인증 과정에서 승인 코드가 도난당해도 이를 사용할 수 없도록 추가적인 비밀 키를 사용해 보안을 강화한다.

암호 그랜트 유형

리소스 소유자 자격 증명 그랜트 유형이라고도 한다.
1단계: 암호 그랜트 유형으로 액세스 토큰 요청
2단계: 암호 그랜트 유형으로 액세스 토큰을 이용해 리소스 호출

1단계: 호텔 체크인 (액세스 토큰 요청)

  • 호텔 로비(앱)에서 체크인하려면 고객(사용자)이 자신의 신분증(아이디와 비밀번호)을 프런트 데스크(인증 서버)에 제출
  • 프런트 데스크(서버)에서는 고객의 신분을 확인하고, 모든 정보가 정확하다면 방 키(액세스 토큰)를 발급

2단계: 호텔 방 입장 (리소스 호출)

  • 고객은 발급받은 방 키(액세스 토큰)를 가지고 호텔 방(서버 리소스) 문을 연다.
    방(서버)방 키(액세스 토큰)가 유효한지 확인하고, 유효하다면 방에 들어갈 수 있게 해준다. (즉, 서버에서 데이터에 접근할 수 있게 되는 것)

이 방식은 보안에 취약할 수 있어 현재 잘 사용하지는 않는다.
예를 들어, 사용자의 자격 증명(아이디와 비밀번호) 을 클라이언트 애플리케이션이 직접 처리하게 되므로, 클라이언트가 신뢰할 수 없는 경우 자격 증명이 노출될 위험이 있다. 현재는 Authorization Code Grant와 PKCE 방식이 더 권장된다.

profile
평범

0개의 댓글