기타/보안

[security] OAuth 2.0의 인가 스펙과 OIDC(OpenID Connect)의 인증 스펙에 대해서 알아봅시다

사바라다 2024. 6. 19. 21:13

개요

안녕하세요. 오늘은 OIDC(OpenID Connect)에 대해서 자세히 알아보는 시간을 가져보도록 하겠습니다. 다들 OAuth2에 대해서는 아실것 같습니다. 잘 모르시는 분들은 [OAuth2] OAuth2 개론 - 개요와 Authorization Code Flow를 통해서 먼저 보고 오시는것을 추천드립니다. OAuth2는 HTTP 기반에서의 권한 부여(Authorizaiton)를 위한 업계 표준 프로토콜입니다. OIDC는 OAuth2의 확장중 하나로써 인증(Authentication)에 대한 프로토콜입니다.

오늘은 인증과 인가의 차이부터 OIDC까지 알아보도록 하겠습니다.

요약

인증과 인가의 차이

  • 인증(Authentication): 사용자의 신원을 확인하는 과정입니다. 로그인과 같은 방식으로 사용자가 누구인지 증명합니다.
  • 인가(Authorization): 인증된 사용자에게 특정 자원에 대한 접근 권한을 부여하는 과정입니다. 접근 제어를 위해 사용됩니다.

OAuth2와 OIDC의 차이점

  • OAuth2: 인가 프로토콜로서, 인증된 사용자에게 자원 접근 권한을 부여하는 것에 중점을 둡니다.
  • OIDC: OAuth 2.0을 확장하여, 사용자의 인증 정보를 안전하게 전달하는 인증 프로토콜입니다.

OIDC 스펙의 특징

  • 표준화된 사용자 정보 제공: 이름, 이메일, 프로필 사진 등 사용자의 신원 정보를 표준화된 형식으로 제공합니다.
  • 인증 시간 및 방법 명시: 사용자가 언제, 어떻게 인증을 받았는지를 명시, 보안 강화에 기여합니다.
  • 세션 및 인증 상태 관리: 사용자의 세션 상태를 관리하고, 로그인 상태 유지 및 로그아웃을 처리합니다.
  • 보안 및 규정 준수: 법적 요구사항을 충족하는 사용자 데이터 처리를 지원합니다.
  • 상호 운용성: 다양한 시스템과의 호환성을 지원하여 표준에 기반한 인증 솔루션을 쉽게 구현할 수 있게 합니다.

OIDC의 ID 토큰 필드 설명

  • iss (Issuer Identifier): 토큰을 발급한 서버의 URL.
  • sub (Subject Identifier): 사용자의 고유 식별자.
  • aud (Audience): 토큰의 수신자 또는 사용 대상.
  • exp (Expiration Time): 토큰의 만료 시간.
  • iat (Issued At): 토큰 발급 시간.
  • auth_time (Authentication Time): 사용자가 마지막으로 인증한 시간.
  • nonce: 재생 공격 방지를 위한 무작위 문자열.
  • at_hash (Access Token Hash): 접근 토큰의 해시 값.
  • email, name, picture: 사용자의 이메일, 이름, 프로필 사진 URL.

상세

인가(Authentication)와 인증(Authorization)

먼저 인가(Authentication)와 인증(Authorization)의 차이에 대해서 알아보도록 하겠습니다.

인가와 인증은 모두 보안적으로 중요한 의미를 가집니다. 간단히 말하면 인증은 허가된 유저만이 서비스를 접근 할 수 있도록 하는 로그인을 뜻하고 인가는 인증된 유저들에게 권한에 대한 의미를 가집니다.

Authentication (인증)
인증은 사용자가 누구인지 확인하는 과정입니다. 이 과정은 일반적으로 사용자의 아이디와 비밀번호를 확인하는 것을 포함합니다. 인증은 또한 생체 인식, OTP (일회용 패스워드), 스마트 카드 등과 같은 다양한 방법을 사용할 수 있습니다. 즉, 인증은 사용자가 서비스에 관련이 있다고 주장하는 바를 증명하는 것입니다.

Authorization (권한 부여, 인가)
권한 부여는 인증된 사용자가 어떤 자원에 접근할 수 있는 권한을 부여하는 과정입니다. 예를 들어, 회사의 서버에 접근할 수 있는 권한을 부여하거나, 특정 데이터를 읽고 수정할 수 있는 권한을 설정하는 것이 여기에 해당합니다. 권한 부여는 주로 접근 제어 목록(Access Control List[ACL]), 역할 기반 접근 제어(Role Based Access Control[RBAC]), 속성 기반 접근 제어(Attributed Base Access Control[ABAC]) 등을 통해 관리됩니다.

OAuth2와 OIDC와의 차이점

OAuth2는 인가(Authorization)에 대한 프로토콜입니다. 이 말인 즉슨 인증된 유저에게 권한을 부여하는 것이 주된 역할입니다. OAuth2의 전체적인 flow는 처음에 인증을 하고 인가에 대한 Access Token을 발급하는 프로세스를 모두 가지고 있습니다만 앞의 인증하는 flow는 권한 부여에 대한 사전 조건이며 권한 부여가 주된 목적이라는 말입니다. OAuth 2.0에서 만들어지는 Access Token은 아래의 조건을 만족합니다.

  • 사용자(리소스 소유자)가 리소스에 대한 접근 권한을 클라이언트 애플리케이션에 부여할 수 있도록 함
  • 사용자는 특정 액션에 대한 권한만을 제한적으로 부여하면서 자신의 데이터를 보호
  • 토큰은 만료 시간을 가지며, 특정 도메인에서만 사용될 수 있도록 설정하여 보안 리스크를 최소화

Access Token의 경우 명세에 따르면 JWT가 아니어도 괘찮습니다만 일반적으로 Client 변조가 불가능한 JWT를 사용하고 그 payload만 가져왔을 때 아래와 같은 필드들을 확인할 수 있습니다. JWT에 대해서는 [JWT] JWT(Json Web Token)에 대해서 자세히 알아봅시다 - 이론편과 [JWT+JAVA] JWT(Json Web Token)에 대해서 자세히 알아봅시다 - 실습편를 참고해주시면 자세히 알 수 있습니다.

{
  "iss": "https://example.com",         // 토큰 발급자
  "sub": "1234567890",                  // 사용자 식별자
  "aud": "https://api.example.com",     // 토큰의 수신자
  "exp": 1516239022,                    // 토큰의 만료 시간
  "scope": "read write"                 // 부여된 권한
}

위 스펙은 jwt 스펙에서 크게 벗어나지 않는 OAuth 2.0 스펙입니다. 우리는 위와 같은 Access Token을 발급받고 각 이를 활용하게 되는데요. 각각 필드의 스펙의 대해서 이야기하면 아래와 같습니다.

  • iss : 토큰 발급자
    • 이 필드는 토큰을 발급한 서버 또는 서비스의 식별자(URL 형태)를 포함합니다.
    • 토큰을 검증할 때, iss 필드를 통해 해당 토큰이 신뢰할 수 있는 출처에서 발급되었는지 확인할 수 있습니다.
  • sub : 사용자의 식별 값
    • sub 필드는 토큰이 참조하는 사용자나 객체의 고유 식별자입니다.
    • 이 식별자는 일반적으로 사용자의 ID나 고유번호가 될 수 있으며, 토큰을 사용하여 API나 리소스에 접근할 때 해당 사용자가 누구인지 식별하는 데 사용됩니다.
  • aud : 토큰의 수신자
    • aud 필드는 토큰이 사용될 대상을 지정합니다.
    • 이 URL은 토큰이 유효하게 사용될 수 있는 리소스 서버나 API의 기반 주소를 나타냅니다.
    • 토큰 수신자가 이 필드를 검증하여 잘못된 수신자가 토큰을 사용하는 것을 방지할 수 있습니다.
  • exp : 만료 일자
    • exp 필드는 토큰이 더 이상 유효하지 않게 되는 시점을 나타내는 유닉스 타임스탬프(초 단위)입니다.
    • 이 시간이 지나면 토큰은 만료되어 접근 권한이 인정되지 않습니다.
    • 이를 통해 토큰의 생명 주기를 제어할 수 있으며, 토큰이 오랜 시간 동안 사용되는 것을 방지하여 보안을 유지합니다.
    • 만료된 토큰은 폐기해야하며 재발급하기 위해서는 refresh token을 이용할 수 있습니다.
  • scope : 부여된 권한
    • scope 필드는 토큰을 사용하여 수행할 수 있는 작업의 범위를 지정합니다.
    • 이 필드는 리소스 서버가 토큰을 받았을 때 해당 사용자가 수행할 수 있는 작업을 결정하는 데 중요한 역할을 합니다.

위 정의된 필드에서 가장 주목해야할 것은 aud와 scope입니다. 왜냐하면 위 두 필드가 권한 부여에 대해서 나타내는 필드이기때문입니다. aud에 scope의 권한을 가지고 있다라는 뜻이기 때문입니다.

그리고 보시면 Access Token은 사용한 유저와 관련된 식별자는 sub 하나뿐인 것을 알 수 있습니다. 이렇게 제한 하는 이유는 OAuth 2.0은 권한 부여와 관련된 프로토콜입니다. 그렇기 때문에 최소 권한 원칙(Principle of Least Privilege)에 따라 관련된 최소한의 정보를 주어 토큰이 탈취되거나 잘못된 손에 넘어가더라도, 사용자의 더 많은 개인정보 노출을 방지할 수 있도록 해야합니다. 이에 따라 sub를 제외한 개인 식별자는 별도로 제공하지 않습니다.

OIDC(OpenID Connect) Spec

OIDC(OpenID Connect)는 OAuth 2.0 프로토콜을 기반으로 상호 인증을 할 수 있는 프로토콜입니다. OIDC 프로토콜은 HTTP 환경에서 OAuth 2.0 flow를 타는 것 만으로도 사용자의 프로필 정보를 얻을 수 있습니다. 그리고 이를 확장하여 사용하는 어플리케이션에서는 SSO 같은 OpenID Provider의 역할, 세션 로그아웃 등을 지원할 수 있습니다.

OIDC는 JWT를 필수적으로 사용해야합니다. 그리고 해당 JWT의 payload에 대한 스펙은 아래와 같습니다. 한눈으로 봤을 때 OAuth 2.0 스펙 보다 더 많은 필드들이 존재하는 것을 알 수 있습니다. 각 필드들에 대해서 아래에서 알아보도록 하겠습니다.

{
  "iss": "https://example.com",
  "sub": "1234567890",
  "aud": "https://app.example.com",
  "exp": 1516239022,
  "iat": 1516235422,            // 토큰 발급 시간
  "auth_time": 1516235000,      // 사용자 인증 시간
  "nonce": "abcdef",            // 무작위 문자열, 재생 공격 방지용
  "at_hash": "XYZ123",          // Access Token 토큰 해시
  "email": "user@example.com",  // 사용자의 이메일
  "name": "John Doe",           // 사용자의 이름
  "picture": "https://example.com/profile.jpg"  // 사용자 프로필 사진 URL
}

제공된 정보는 OpenID Connect 프로토콜에 따른 ID 토큰의 예시입니다. 이 토큰은 사용자의 인증 정보와 함께 특정 권한 부여 세션에 대한 상세 정보를 포함합니다. 각 필드의 의미는 다음과 같습니다.

Access Token과 동일한 영역

  • iss : 토큰 발급자
    • 이 필드는 토큰을 발급한 서버 또는 서비스의 식별자(URL 형태)를 포함합니다.
    • 토큰을 검증할 때, iss 필드를 통해 해당 토큰이 신뢰할 수 있는 출처에서 발급되었는지 확인할 수 있습니다.
  • sub : 사용자의 식별 값
    • sub 필드는 토큰이 참조하는 사용자나 객체의 고유 식별자입니다.
    • 이 식별자는 일반적으로 사용자의 ID나 고유번호가 될 수 있으며, 토큰을 사용하여 API나 리소스에 접근할 때 해당 사용자가 누구인지 식별하는 데 사용됩니다.
  • aud : 토큰의 수신자
    • aud 필드는 토큰이 사용될 대상을 지정합니다.
    • 이 URL은 토큰이 유효하게 사용될 수 있는 리소스 서버나 API의 기반 주소를 나타냅니다.
    • 토큰 수신자가 이 필드를 검증하여 잘못된 수신자가 토큰을 사용하는 것을 방지할 수 있습니다.
  • exp : 만료 일자
    • exp 필드는 토큰이 더 이상 유효하지 않게 되는 시점을 나타내는 유닉스 타임스탬프(초 단위)입니다.
    • 이 시간이 지나면 토큰은 만료되어 접근 권한이 인정되지 않습니다.
    • 이를 통해 토큰의 생명 주기를 제어할 수 있으며, 토큰이 오랜 시간 동안 사용되는 것을 방지하여 보안을 유지합니다.
    • 만료된 토큰은 폐기해야하며 재발급하기 위해서는 refresh token을 이용할 수 있습니다.

OpenID Connect Core 1.0 스펙

  • iat (Issued At)
    • 토큰이 발급된 시간을 나타냅니다.
    • 이 필드는 토큰이 생성된 시점의 유닉스 타임스탬프를 포함하며, 토큰 발급 시간을 추적하는 데 사용됩니다.
  • auth_time (Authentication Time)
    • 사용자가 마지막으로 인증한 시간을 나타냅니다.
    • 이 필드는 사용자가 인증 과정을 완료한 시점의 유닉스 타임스탬프를 포함하며, 사용자가 언제 인증을 받았는지를 나타냅니다.
  • nonce (Nonce)
    • Replay Attack을 방지하기 위한 무작위 문자열입니다.
    • 이 필드는 토큰 요청 시 사용된 무작위 문자열을 포함하며, 토큰이 재사용되는 것을 방지하는 데 사용됩니다.
    • 서버에서는 동일한 nonce를 받으면 실패처리합니다.
  • at_hash (Access Token Hash)
    • Access Token의 해시 값을 제공합니다.
    • 해시값의 전체값을 사용하기보다는 앞의 일부분을 사용합니다.
    • 이 필드는 접근 토큰의 해시를 포함하여, ID 토큰이 발급될 때 사용된 접근 토큰과의 일치를 확인하는 데 사용됩니다.

추가적인 선택적 클레임

  • email
    • 사용자의 이메일 주소를 제공합니다.
    • 이 필드는 사용자의 이메일 주소를 포함하여, 사용자를 더 명확하게 식별하거나 연락할 수 있는 수단을 제공합니다.
  • name
    • 사용자의 이름을 제공합니다.
    • 이 필드는 사용자의 전체 이름을 포함하며, 사용자 인터페이스에서 사용자를 인사하거나 식별하는 데 사용될 수 있습니다.
  • picture
    • 사용자의 프로필 사진 URL을 제공합니다.
    • 이 필드는 사용자의 프로필 사진을 가리키는 URL을 포함하여, 사용자의 시각적 식별을 가능하게 합니다.

OAuth 2.0의 sub 필드를 통해서 Resource Server를 호출하는 것에 비해서 어떤것이 장점인가 ?

OIDC를 보면 사용자의 정보를 제공합니다. 사실 이러한 정보들은 경우에 따라서 Access Token을 통해서 Resource에 한번 더 접근한다면 얻을 수 있는 정보일 수 있습니다. 두 방법의 차이에 대해서 OIDC를 쓰는것의 특징을 중심으로 알아보도록 하겠습니다.

표준화된 사용자 신원 정보
OpenID Connect는 ID 토큰을 통해 표준화된 방법으로 사용자의 신원 정보를 제공합니다. sub 필드는 사용자를 식별하는 데 사용되지만, 이 외에도 사용자의 이름(name), 이메일(email), 프로필 사진(picture) 등 사용자에 대한 더 많은 정보를 포함할 수 있습니다. 이러한 정보는 사용자 경험을 개인화하고, 사용자가 별도의 등록 절차 없이 서비스를 이용할 수 있도록 해줍니다.

인증 시간과 방법의 명시
OpenID Connect에서는 사용자가 언제(auth_time), 어떤 방법으로 인증했는지(예: 비밀번호, 생체 인증)를 명시할 수 있습니다. 이 정보는 보안 강화에 중요한 요소로 작용할 수 있으며, 특히 규제가 엄격한 환경에서 필요한 사용자 인증의 유효성을 검증하는 데 도움을 줍니다.

세션 및 인증 상태 관리
OpenID Connect는 사용자의 세션과 인증 상태를 관리하는 데 필요한 메커니즘을 제공합니다. nonce와 같은 필드를 통해 재생 공격을 방지하고, 사용자가 로그인한 상태를 유지하거나 로그아웃 할 때 필요한 정보를 안전하게 처리할 수 있습니다.

보안과 규정 준수
OpenID Connect는 보안 및 개인 정보 보호와 관련된 규정 준수 요구 사항을 지원하기 위해 설계되었습니다. 예를 들어, 유럽의 일반 데이터 보호 규정(GDPR)과 같은 법률을 준수하는 데 필요한 사용자 동의와 데이터 처리 정보를 포함할 수 있습니다.

결론적으로, OAuth 2.0이 제공하는 sub 필드는 기본적인 사용자 식별 기능을 제공하지만, OpenID Connect는 프로토콜을 지킴으로써 사용자의 신원을 보다 풍부하고 안전하게 관리할 수 있는 표준화된 방법을 제공합니다. 이로 인해 사용자 경험을 향상시키고, 보안을 강화하며, 규정 준수를 보장하는 등의 이점을 제공합니다.

참조

반응형
저작자표시