개발/Spring Security

OAuth2

Debin 2023. 3. 20.
반응형

OAuth2

위키피디아의 OAuth 정의는 다음과 같다.

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

 

OAuth는 Open Authorization의 약어다.

OAuth는 인터넷 프로토콜, 즉 통신을 하기 위한 약속이다.

권한 부여 프레임워크라고 부르는 경우가 많다. 타사 웹 사이트나 웹이 리소스에 접근할 수 있게 허용하는 것이 주 목적이다.

그리고 프로토콜이므로 OAuth2 흐름 정의와 함께 다른 플랫폼, 도구, 언어를 적용할 수 있다.

 

OAuth2는 OAuth보다 업그레이드 된 버전이라고 생각하면 되겠다.

OAuth2 인증 아키텍처의 구성 요소

OAuth2 구성 요소는 크게 4가지가 있다.

리소스 서버

  • 타사 애플리케이션에서 접근하는 사용자의 자원이 포함된 서버다.
  • 액세스 토큰을 수락 및 검증할 수 있어야 하며 권한 체계에 따라 요청을 승인할 수 있어야 한다.

리소스 소유자

  • 리소스 서버가 노출하는 리소스를 소유하는 개인. 보호된 자원에 대한 접근을 부여할 수 있는 개인.
  • 사용자를 대신하여 작동하려는 모든 클라이언트는 사용자의 허가를 받아야 한다.

클라이언트

  • 사용자를 대신해 사용자가 소유한 리소스에 접근하는 애플리케이션.
  • 사용자를 권한 부여 서버로 안내하거나 사용자의 상호 작용 없이 권한 부여 서버로부터 직접 권한을 얻을 수 있다.

권한부여 서버

  • 클라이언트가 리소스 서버가 노출하는 사용자의 리소스에 접근할 권한을 부여하는 애플리케이션.
  • 권한 부여 서버는 클라이언트가 사용자 대신 리소스에 접근 권한이 있다고 결정하면 토큰을 발급한다.
  • 클라이언트는 이 토큰을 이용해 권한 부여 서버에서 권한을 받았음을 리소스 서버에 증명한다,.
  • 리소스 서버는 유효한 토큰이 있으면 클라이언트가 요청한 리소스에 접근하게 허용한다.

OAuth2 권한 부여 유형

1. Authorization Code Grant Type

  • 승인 코드 부여 타입이다. 보안에 가장 안전한 유형이고 제일 많이 사용되는 일반적인 방식이다.

과정은 다음과 같다.

 

  1. 인가 서버에게 code를 요청한다. code는 access Token과 교환할 것이다.
  2. 사용자의 승인 및 동의하에 인가서버가 클라이언트에게 코드를 발급한다.
  3. 클라이언트의 권한 부여가 승인되고 그 결과로 access Token을 획득한다.
  4. 이 access Token을 가지고 리소스 서버에 접근해 리소스를 얻는다.

2. Implicit Grant Type (Deprecated)

  • 암시적 부여 타입이다. URL에 액세스 토큰이 노출되어 보안에 취약하다.
  • 공개 클라이언트 애플리케이션에서 보통 사용했으며 현재는 Deprecated 되었다.

3. Resource Owner Password Credentials Grant Type(Deprecated)

  • 리소스 사용자 비밀번호 자격 증명 부여 타입이다. 
  • 애플리케이션이 사용자 이름과 액세스 토큰으로 교환할 때 사용된다.
  • 타사 애플리케이션이 이 권한을 사용하도록 허용해서는 안되고 고도의 신뢰할 자사 애플리케이션만 사용해야 한다.
  • 즉 보안이 낮다는 뜻이다.

4. Client Credentials Grant Type

  • 클라이언트 자격 증명 권한 부여 타입이다.
  • 애플리케이션이 리소스 소유자인 동시에 클라이언트의 역할을 한다.
  • 서버대 서버간의 통신에 사용할 수 있으며 IOT와 같은 장비 애플리케이션과의 통신을 위한 인증으로도 활용할 수 있다.
  • 리소스 소유자에게 권한 위임 받아 리소스에 접근하는 것이 아니라 자기 자신이 애플리케이션을 사용할 목적으로 사용한다.
  • Client 정보를 기반으로 하기 때문에 사용자 정보를 제공하지 않는다.
  • Authorization Code Grant Type과 비슷하며 다른점은 리소스 소유자의 자격 증명이 필요없다는 점이다.

과정은 다음과 같다.

 

  1. 자격증명이 필요 없으므로 바로 access Token을 요청하고 이를 받는다.
  2. 그러면 access Token으로 리소스 서버에 접근해서 이를 얻고 리소스를 사용한다.

5. Refresh Token Grant Type

  • 액세스 토큰이 발급될 때 함께 제공되는 토큰으로서 액세스 토큰이 만료되더라도 함께 발급 받았던 리프레시 토큰이 유효하다면, 인증 과정을 처음부터 반복하지 않아도 액세스 토큰을 재발급 받을 수 있다.
  • 한 번 사용된 리프레시 토큰은 폐기되거나 재사용할 수 있다.

과정은 다음과 같다.

 

  1. access Token을 요청해 이를 얻는다. 이때 refresh Token도 같이 얻는다.
  2. 이후 계속 사용하다가 access Token이 만료되었을 때, refresh Token으로 인가 서버에 요청을 한다.
  3. 그럼 refresh Token을 검증하고 성공한다면 access Token을 돌려준다.
  4. 이 accessToken을 사용해 리소스 서버에 접근하고 리소스를 활용한다.

6. PKCE-enhanced Authorization Code Grant Type

  • 코드 교환을 위한 증명 키로서 CSRF 및 권한 부여 코드 삽입 공격 위한 Authorization Code Grant Flow의 확장버전이다.
  • 권한부여코드 요청시 Code Verifier와 Code Challenge를 추가하여 만약 Authorization Code Grant Flow에서 Authrozization Code가 탈취당했을 때 Access Token을 발급하지 못하도록 차단한다.
  • PKCE는 원래 모바일 앱에서 Authorization Code Grant Flow를 보호하도록 설계되었으며 나중에 단일 페이지 앱에서도 사용하도록 권장되며 모든 유형의 OAuth2 클라이언트, 심지어 클라이언트 암호를 사용하는 웹 서버에서 실행되는 앱에도 유용하다.

요청 URL에 추가되는 쿼리파라미터를 살펴보자.

 

  • code verifier: 권한 부여 코드 요청 전에 맵이 원래 생성한 PKCE에 대한 코드 검증기
  • code_challenge_method: S256 해시 알고리즘 또는 특정한 알고리즘을 사용하지 않도록 설정
  • code challenge: 선택한 해시 알고리즘으로 CodeVerifier를 해싱한 후 Base 64 인코딩을 한 값

Authorization Code Grant Type에서 처음 권한 부여 코드 요청시에 code_challenge와 code_challenge_method가 쿼리 파라미터로 추가 되었고, access_Token 요청 시 쿼리 파라미터로 code_verifier이 추가되었다.

OAuth2 허점

  • 클라이언트에서 CSRF 이용
  • 클라이언트 자격 증명 도용
  • 토큰 재생 및 토큰 탈취

OpenID Connect

  • OpenID Connect 1.0은 OAuth2.0 계층 위에 구축된 ID 계층으로 OAuth2.0을 확장하여 인증 방식을 표준화 한 OAuth2.0 기반의 인증 프로토콜이다.
  • scope 지정 시 "openId"를 포함하면 OpenID Connect 사용이 가능하며 인증에 대한 정보는 ID 토큰이라고 하는 JWT로 반환된다.
  • OpenID Connect 클라이언트가 사용자 ID를 확인할 수 있게 하는 보안 토큰인 ID Token을 제공한다.
  • OAuth2가 인가용이라면, OpenID는 인증용이다.

OIDC 상호 작용 행위자

OpenID Provider

줄여서 OP라고 하며 OpenID 제공자로서 최종 사용자를 인증하고 인증 결과와 사용자에 대한 정보를 신뢰 당사자에게 제공할 수 있는 OAuth2.0 서버를 의미한다.

Relying Party

  • 줄여서 RP라고 하며 신뢰 당사자로서 인증 요청을 처리하기 위해 OP에 의존하는 Oauth2.0 애플리케이션을 말한다.

흐름은 아래와 같다.

 

  1. RPS는 OP에 권한 부여 요청을 보낸다.
  2. OP는 최종 사용자를 인증하고 권한을 얻는다.
  3. OP는 ID 토큰과 액세스 토큰으로 응답한다.
  4. RP는 액세스 토큰을 사용하여 UserInfo 엔드포인트에 요청을 보낼 수 있다.
  5. UserInfo 엔드포인트는 최종 사용자에 대한 클레임을 반환한다.

 

참고자료

스프링 시큐리티 인 액션

 

https://www.inflearn.com/course/%EC%A0%95%EC%88%98%EC%9B%90-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0/dashboard

 

스프링 시큐리티 OAuth2 - Spring Boot 기반으로 개발하는 Spring Security OAuth2 - 인프런 | 강의

스프링 시큐리티 OAuth2의 기본 개념부터 API 사용법과 내부 아키텍처를 학습합니다. 아울러 OAuth2 Client, OAuth2 Resource Server, Authorization Server를 통합하여 연동하는 방법을 살펴보고 자체 인가 서버를

www.inflearn.com

 

반응형

댓글