반응형
OAuth2
위키피디아의 OAuth 정의는 다음과 같다.
인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
OAuth는 Open Authorization의 약어다.
OAuth는 인터넷 프로토콜, 즉 통신을 하기 위한 약속이다.
권한 부여 프레임워크라고 부르는 경우가 많다. 타사 웹 사이트나 웹이 리소스에 접근할 수 있게 허용하는 것이 주 목적이다.
그리고 프로토콜이므로 OAuth2 흐름 정의와 함께 다른 플랫폼, 도구, 언어를 적용할 수 있다.
OAuth2는 OAuth보다 업그레이드 된 버전이라고 생각하면 되겠다.
OAuth2 인증 아키텍처의 구성 요소
OAuth2 구성 요소는 크게 4가지가 있다.
리소스 서버
- 타사 애플리케이션에서 접근하는 사용자의 자원이 포함된 서버다.
- 액세스 토큰을 수락 및 검증할 수 있어야 하며 권한 체계에 따라 요청을 승인할 수 있어야 한다.
리소스 소유자
- 리소스 서버가 노출하는 리소스를 소유하는 개인. 보호된 자원에 대한 접근을 부여할 수 있는 개인.
- 사용자를 대신하여 작동하려는 모든 클라이언트는 사용자의 허가를 받아야 한다.
클라이언트
- 사용자를 대신해 사용자가 소유한 리소스에 접근하는 애플리케이션.
- 사용자를 권한 부여 서버로 안내하거나 사용자의 상호 작용 없이 권한 부여 서버로부터 직접 권한을 얻을 수 있다.
권한부여 서버
- 클라이언트가 리소스 서버가 노출하는 사용자의 리소스에 접근할 권한을 부여하는 애플리케이션.
- 권한 부여 서버는 클라이언트가 사용자 대신 리소스에 접근 권한이 있다고 결정하면 토큰을 발급한다.
- 클라이언트는 이 토큰을 이용해 권한 부여 서버에서 권한을 받았음을 리소스 서버에 증명한다,.
- 리소스 서버는 유효한 토큰이 있으면 클라이언트가 요청한 리소스에 접근하게 허용한다.
OAuth2 권한 부여 유형
1. Authorization Code Grant Type
- 승인 코드 부여 타입이다. 보안에 가장 안전한 유형이고 제일 많이 사용되는 일반적인 방식이다.
과정은 다음과 같다.
- 인가 서버에게 code를 요청한다. code는 access Token과 교환할 것이다.
- 사용자의 승인 및 동의하에 인가서버가 클라이언트에게 코드를 발급한다.
- 클라이언트의 권한 부여가 승인되고 그 결과로 access Token을 획득한다.
- 이 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과 비슷하며 다른점은 리소스 소유자의 자격 증명이 필요없다는 점이다.
과정은 다음과 같다.
- 자격증명이 필요 없으므로 바로 access Token을 요청하고 이를 받는다.
- 그러면 access Token으로 리소스 서버에 접근해서 이를 얻고 리소스를 사용한다.
5. Refresh Token Grant Type
- 액세스 토큰이 발급될 때 함께 제공되는 토큰으로서 액세스 토큰이 만료되더라도 함께 발급 받았던 리프레시 토큰이 유효하다면, 인증 과정을 처음부터 반복하지 않아도 액세스 토큰을 재발급 받을 수 있다.
- 한 번 사용된 리프레시 토큰은 폐기되거나 재사용할 수 있다.
과정은 다음과 같다.
- access Token을 요청해 이를 얻는다. 이때 refresh Token도 같이 얻는다.
- 이후 계속 사용하다가 access Token이 만료되었을 때, refresh Token으로 인가 서버에 요청을 한다.
- 그럼 refresh Token을 검증하고 성공한다면 access Token을 돌려준다.
- 이 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 애플리케이션을 말한다.
흐름은 아래와 같다.
- RPS는 OP에 권한 부여 요청을 보낸다.
- OP는 최종 사용자를 인증하고 권한을 얻는다.
- OP는 ID 토큰과 액세스 토큰으로 응답한다.
- RP는 액세스 토큰을 사용하여 UserInfo 엔드포인트에 요청을 보낼 수 있다.
- UserInfo 엔드포인트는 최종 사용자에 대한 클레임을 반환한다.
참고자료
스프링 시큐리티 인 액션
반응형
댓글