OpenID Connect: 맞춤형에서 표준으로 내부 애플리케이션 인증

몇 달 전에 저는 수백 개의 내부 애플리케이션에 대한 액세스를 관리하기 위해 OpenID Connect 서버를 구현하고 있었습니다. 자체 개발에서 더 작은 규모로 편리하게 일반적으로 허용되는 표준으로 이동했습니다. 중앙 서비스를 통한 액세스는 단조로운 작업을 크게 단순화하고 인증 구현 비용을 줄이며 새로운 솔루션을 개발할 때 머리를 숙이지 않고 많은 기성 솔루션을 찾을 수 있습니다. 이 기사에서는 이러한 전환과 우리가 채울 수 있었던 범프에 대해 이야기할 것입니다.

오래 전에... 모든 것이 어떻게 시작되었는지

몇 년 전 수동 제어를 위한 내부 애플리케이션이 너무 많았을 때 회사 내에서 액세스를 제어하는 ​​애플리케이션을 작성했습니다. 다양한 기능에 대한 액세스가 구성된 직원 정보가 포함된 데이터베이스에 연결된 간단한 Rails 애플리케이션이었습니다. 동시에 우리는 클라이언트 측과 인증 서버 측의 토큰 검증을 기반으로 하는 첫 번째 SSO를 제기했으며, 토큰은 여러 매개변수와 함께 암호화된 형태로 전송되고 인증 서버에서 검증되었습니다. 각 내부 응용 프로그램이 상당한 수준의 논리를 설명해야 하고 직원 데이터베이스가 인증 서버와 완전히 동기화되었기 때문에 이것은 가장 편리한 옵션이 아니었습니다.

얼마 후 중앙 집중식 인증 작업을 단순화하기로 결정했습니다. SSO가 밸런서로 전송되었습니다. OpenResty의 도움으로 토큰을 확인하는 템플릿이 Lua에 추가되었고, 요청이 어떤 애플리케이션으로 가는지 알고 거기에 액세스가 있는지 확인할 수 있습니다. 이 접근 방식은 내부 애플리케이션에 대한 액세스를 제어하는 ​​작업을 크게 단순화했습니다. 각 애플리케이션의 코드에서 더 이상 추가 논리를 설명할 필요가 없었습니다. 결과적으로 우리는 트래픽을 외부적으로 차단했고 애플리케이션 자체는 승인에 대해 아무것도 알지 못했습니다.

그러나 한 가지 문제가 해결되지 않았습니다. 직원에 대한 정보가 필요한 애플리케이션은 어떻습니까? 인증 서비스에 대한 API를 작성할 수 있었지만 그런 경우 각 애플리케이션에 대해 추가 로직을 추가해야 했습니다. 또한 우리는 내부 인증 서버에서 향후 OpenSource로 변환하기 위해 지향하는 자체 작성 애플리케이션 중 하나에 대한 의존성을 없애고 싶었습니다. 우리는 그것에 대해 다른 시간에 이야기할 것입니다. 두 문제에 대한 해결책은 OAuth였습니다.

공통 표준에

OAuth는 이해할 수 있고 일반적으로 인정되는 인증 표준이지만 기능만으로는 충분하지 않기 때문에 즉시 OIDC(OpenID Connect)를 고려하기 시작했습니다. OIDC 자체는 개방형 인증 표준의 세 번째 구현이며 OAuth 2.0 프로토콜(개방형 인증 프로토콜)을 통해 추가 기능으로 유입되었습니다. 이 솔루션은 최종 사용자에 대한 데이터 부족 문제를 해결하고 인증 공급자를 변경할 수도 있습니다.

그러나 특정 공급자를 선택하지 않고 기존 인증 서버에 OIDC와의 통합을 추가하기로 결정했습니다. 이 결정에 유리한 점은 OIDC가 최종 사용자 인증 측면에서 매우 유연하다는 점입니다. 따라서 현재 인증 서버에서 OIDC 지원을 구현하는 것이 가능했습니다.

자체 OIDC 서버를 구현하는 방법

1) 데이터를 원하는 형태로 가져옴

OIDC를 통합하려면 현재 사용자 데이터를 표준에서 이해할 수 있는 형태로 가져와야 합니다. OIDC에서는 이를 클레임이라고 합니다. 클레임은 본질적으로 사용자 데이터베이스의 최종 필드(이름, 이메일, 전화 등)입니다. 존재한다 표준 우표 목록, 이 목록에 포함되지 않은 모든 항목은 사용자 정의로 간주됩니다. 따라서 기존 OIDC 사업자를 선택하고자 할 때 가장 먼저 주목해야 할 점은 신규 브랜드의 편리한 커스터마이징 가능성이다.

특징 그룹은 다음 하위 집합인 범위로 결합됩니다. 승인하는 동안 범위의 일부 브랜드가 필요하지 않은 경우에도 특정 브랜드가 아니라 범위에 대한 액세스가 요청됩니다.

2) 필요한 교부금 시행

OIDC 통합의 다음 부분은 권한 부여 유형인 권한 부여의 선택 및 구현입니다. 선택한 응용 프로그램과 인증 서버 간의 추가 상호 작용 시나리오는 선택한 승인에 따라 달라집니다. 올바른 보조금을 선택하는 예시적인 체계가 아래 그림에 나와 있습니다.

첫 번째 신청에서는 가장 일반적인 권한 부여인 인증 코드를 사용했습니다. 다른 것과의 차이점은 XNUMX단계, 즉 추가 테스트 중입니다. 먼저 사용자가 인증 권한을 요청하고 인증 코드(Authorization Code)라는 토큰을 받은 다음 이 토큰으로 마치 여행 티켓처럼 액세스 토큰을 요청합니다. 이 권한 부여 스크립트의 모든 주요 상호 작용은 응용 프로그램과 권한 부여 서버 간의 리디렉션을 기반으로 합니다. 이 보조금에 대한 자세한 내용을 읽을 수 있습니다. 여기에.

OAuth는 권한 부여 후 얻은 액세스 토큰이 일시적이어야 하며 가급적 평균 10분마다 변경되어야 한다는 개념을 고수합니다. 인증 코드 부여는 리디렉션을 통한 10단계 인증으로, XNUMX분마다 이러한 단계를 전환하는 것은 솔직히 눈에 가장 즐거운 작업이 아닙니다. 이 문제를 해결하기 위해 우리나라에서도 사용되는 Refresh Token이라는 또 다른 보조금이 있습니다. 여기서 모든 것이 더 쉽습니다. 다른 승인에서 확인하는 동안 기본 액세스 토큰 외에도 한 번만 사용할 수 있고 일반적으로 수명이 훨씬 더 긴 새로 고침 토큰이라는 또 다른 토큰이 발급됩니다. 이 Refresh Token을 사용하면 기본 액세스 토큰의 TTL(Time to Live)이 종료되면 새 액세스 토큰에 대한 요청이 다른 권한 부여의 끝점으로 올 것입니다. 사용한 새로 고침 토큰은 즉시 XNUMX으로 재설정됩니다. 이 검사는 XNUMX단계로 이루어지며 사용자가 인지하지 못하는 사이에 백그라운드에서 수행할 수 있습니다.

3) 사용자 지정 데이터 출력 형식 설정

선택한 권한 부여가 구현되고 인증이 작동하면 최종 사용자에 대한 데이터를 가져오는 것을 언급할 가치가 있습니다. OIDC에는 이를 위한 별도의 엔드포인트가 있으며, 여기에서 현재 액세스 토큰과 최신 상태인 경우 사용자 데이터를 요청할 수 있습니다. 그리고 사용자의 데이터가 자주 변경되지 않고 현재 데이터를 여러 번 따라야 하는 경우 JWT 토큰과 같은 솔루션을 사용할 수 있습니다. 이러한 토큰은 표준에서도 지원됩니다. JWT 토큰 자체는 헤더(토큰에 대한 정보), 페이로드(필요한 데이터) 및 서명(서명, 토큰은 서버에서 서명하고 나중에 서명 소스를 확인할 수 있음)의 세 부분으로 구성됩니다.

OIDC 구현에서 JWT 토큰은 id_token이라고 합니다. 일반 액세스 토큰과 함께 요청할 수 있으며 남은 것은 서명을 확인하는 것입니다. 인증 서버에는 다음과 같은 형식의 여러 공개 키가 있는 별도의 엔드포인트가 있습니다. J.W.K.. 그리고 이것에 대해 말하자면, 표준을 기반으로 하는 또 다른 엔드포인트가 있다는 것을 언급할 가치가 있습니다. RFC5785 OIDC 서버의 현재 구성을 반영합니다. 여기에는 모든 엔드포인트 주소(서명에 사용되는 공개 키 링의 주소 포함), 지원되는 브랜드 및 범위, 사용되는 암호화 알고리즘, 지원되는 보조금 등이 포함됩니다.

예를 들어 Google에서:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

따라서 id_token을 사용하면 필요한 모든 특징을 토큰의 페이로드로 전송할 수 있으며 사용자 데이터를 요청하기 위해 매번 인증 서버에 접속하지 않아도 됩니다. 이 접근 방식의 단점은 서버에서 사용자 데이터가 즉시 변경되지 않고 새 액세스 토큰과 함께 변경된다는 것입니다.

시행 결과

따라서 자체 OIDC 서버를 구현하고 애플리케이션 측에서 이에 대한 연결을 구성한 후 사용자 정보 전송 문제를 해결했습니다.
OIDC는 개방형 표준이므로 기존 공급자 또는 서버 구현을 선택할 수 있습니다. 애플리케이션 측에서 연결 구성을 설정하고 변경한 후 구성이 매우 편리한 것으로 판명된 Keycloak를 사용해 보았습니다. 애플리케이션 측면에서 남은 것은 연결 구성을 변경하는 것입니다.

기존 솔루션에 대해 이야기하기

우리 조직 내에서 최초의 OIDC 서버로서 필요에 따라 보완되는 자체 구현을 조립했습니다. 다른 기성 솔루션을 자세히 검토한 후 이것이 논점이라고 말할 수 있습니다. 자체 서버를 구현하기로 한 결정에 찬성하여 일부 서비스에 대해 서로 다른 사용자 정의 인증이 있는 오래된 시스템의 존재뿐만 아니라 필요한 기능이 없는 공급자 측에 대한 우려가 있었습니다. 직원에 대한 데이터는 이미 저장되어 있습니다. 그러나 기성품 구현에는 통합에 대한 편의가 있습니다. 예를 들어 Keycloak에는 자체 사용자 관리 시스템이 있고 데이터가 직접 저장되므로 사용자를 추월하는 것이 어렵지 않습니다. 이를 위해 Keycloak에는 필요한 모든 전송 작업을 완전히 수행할 수 있는 API가 있습니다.

내 생각에 인증되고 흥미로운 구현의 또 다른 예는 Ory Hydra입니다. 그것은 다른 구성 요소로 구성되어 있기 때문에 흥미 롭습니다. 통합하려면 사용자 관리 서비스를 인증 서비스에 연결하고 필요에 따라 확장해야 합니다.

Keycloak과 Ory Hydra만이 기성 솔루션이 아닙니다. OpenID Foundation에서 인증한 구현을 선택하는 것이 가장 좋습니다. 이러한 솔루션에는 일반적으로 OpenID 인증 배지가 있습니다.

또한 OIDC 서버를 유지하지 않으려는 경우 기존 유료 공급자를 잊지 마십시오. 오늘날에는 좋은 옵션이 많이 있습니다.

다음 단계

가까운 시일 내에 내부 서비스에 대한 트래픽을 다른 방식으로 차단할 예정입니다. OpenResty를 사용하여 균형 장치의 현재 SSO를 OAuth 기반 프록시로 이전할 계획입니다. 여기에는 이미 많은 기성 솔루션이 있습니다. 예를 들면 다음과 같습니다.
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

추가 자료

jwt.io – JWT 토큰 유효성 검사를 위한 좋은 서비스
openid.net/developers/certified - 인증된 OIDC 구현 목록

출처 : habr.com