OAuth

Open Authorization 직역하면, 공개 인증이라는 의미이다.

다른 웹 서비스에게 이용중인 서비스에 있는 나의 정보에 접근할 수 있는 권한을 공개하여 인증할 수 있도록 접근 위임을 통한 인증을 수행한다..

OAuth 1.0 의 등장

2007년 12월, OAuth 가 등장했다. 실제로 트위터 등 대형 서비스에서도 도입을 시작하였고

2008년 ~ 2010년 까지 구글에서 OAuth 1.0 을 지원해왔다.

하지만 OAuth 1.0 버전에는, 암호화 구현 및 암호화 상호 운용성이 필요했고 개발자들이 이를 구현하기에는 꽤나 어려운 작업이 요구되었다.

OAuth 2.0 의 등장

참고자료 - OAuth 공식문서

참고자료 - 카카오페이 기술 블로그

그래서 암호화 구현을 미리 포함해놓은 OAuth 2.0 이 등장했다. 이 과정에는 많은 대기업이 OAuth 표준 을 제정하는데에 일조한 배경이 있다.

따라서 OAuth 2.0 은 더 사용하기 쉬워진 개선된 버전이라고 보면 된다.

OAuth 1.0 의 특징

HTTPS/TLS 에 보안을 맡기는 방법이 아닌, 자체적인 보안 인증을 수행한다.
메세지의 무결성과 신뢰성을 증명하기 위해, 디지털 서명을 수행한다.
통신 과정에서 하나의 요청에 대해 여러 메세지로 나뉠 수 있다. 이 때 각 메세지마다 암호화를 수행하여, 어느 한 메세지라도 부적절하다면 그 전체 트랜잭션은 무효화된다.

OAuth 2.0 의 특징

OAuth 1.0과 달리 대부분의 보안 방어는 HTTPS/TLS에 위임된다.
오타, 부적절한 TLS 구성, 인증서 유효성 검사 실패 또는 기본 라이브러리의 취약점으로 인해
MitM(Man-in-the-Middle) 공격이 발생하여 모든 OAuth 통신이 손상될 수 있다.
bearer(무기명) 토큰은 통합하기 쉽지만 보안에는 좋지 않다. bearer(무기명) 토큰은 내부 보안 메커니즘을 제공하지 않아 복사하거나 훔칠 수 있지만 구현하기가 더 쉽다.
OAuth 2.0은 훨씬 더 쉽게 사용할 수 있지만, 안전하게 빌드하기가 훨씬 더 어렵다.
OAuth 1.0 은 Web-Workflow 만 처리했지만 OAuth 2.0 은 Web 뿐만아니라 Client 또한 고려한다.
리소스 요청 처리, 사용자 권한 부여 처리로 역할을 분리하여 사용할 수 있다.

OAuth 기본 용어

1. Resource Owner

Protected Resource에 대한 접근을 허용하는 주체이며 대부분의 IT 서비스에서는 End-User(사용자)를 의미
자원에 대한 접근을 허가해 줄 수 있는 주체
즉, Google, Kakao, Facebook 등 소셜 미디어 사용자를 가리킨다.

2. Resource Server

Resource Server: Access Token을 검증하고 Protected Resource를 제공하는 서버
자원을 호스팅하는 서버
즉, Google서버, Kakao서버, Facebook 서버 등 소셜 미디어의 서버를 가리킨다.

3. Client

Protected Resource를 사용하고 싶어하는 주체이며 웹앱, 모바일앱, 기타 프로그램 등 Resource Owner가 Service에 접근할 때 사용하는 프로그램을 의미
Resource Server에서 제공하는 자원을 사용하는 애플리케이션
Spring이 해줄 수 있는 역할로, Google 프로필 사진을 내 DB에 저장하는 등의 기능을 수행할 수 있다.

4. Authorization Server

Resource Owner의 인가를 확인하고 Access Token을 발급하는 서버
사용자(Resource Owner)의 동의를 받아서(OAuth 를 수행해서) 권한을 부여하는 서버를 가리킨다.

OAuth Workflow - 가장 중요함!!

(A), (B): Resource Owner로부터 Resource Server에 대한 인증/인가를 수행하도록 한다.
(C), (D): Resource Server에서 수행한 인가를 증명하여 Authorization Server로부터 Access Token 획득
(E), (F): Access Token으로 Protected Resource 접근 권한 획득

위 과정을 조금 더 구체적인 명칭을 포함해본다면

Spring -> GitHub User [GitHub 사용자에게 GitHub의 인가 요청]
GitHub OAuth Server -> Spring [GitHub 사용자로부터 인가 정보 획득]
Spring -> GitHub Authorization Server [GitHub 인가 서버에 인가 요청]
GitHub Authorization Server -> Spring [GitHub 인가 서버로부터 인가 획득]
Spring GitHub User’s AccessToken -> GitHub Server [GitHub 유저의 AccessToken을 GitHub Server에 전송]
GitHub Server -> Spring [사용자 정보 전달]

Spring Security와 Authorization Server

  
@Bean
fun filterChain(
    http: HttpSecurity,
    ...
): SecurityFilterChain {
    OAuth2AuthorizationServerConfigurer()
        .apply { http.apply(this) } // OAuth2AuthorizationServerConfigurer 등록
        .registeredClientRepository(registeredClientRepository) // Client Credentials 데이터 저장소 등록
        .authorizationService(authorizationService) // OAuth Authorization (Access Token) 내역 데이터 저장소 등록
        .tokenGenerator(JwtGenerator(jwtEncoder)) // Access Token은 JWT 선택 (기본 구현은 Opaque Token)
        .authorizationServerSettings(settings) // Authorization Server 환경 셋팅 (예: Token Endpoint 커스터마이징)
    // ...
    return http.build()
    }

OAuth 1.0 && 2.0