앱의 인증 및 권한 부여
보안은 최신 웹 애플리케이션에 매우 중요합니다. 웹 애플리케이션 아키텍처의 일부인 Fluid Framework는 보안을 유지해야 하는 중요한 인프라입니다. Fluid Framework는 계층화된 아키텍처이며 인증 관련 개념은 연결하는 Fluid 서비스를 기반으로 구현됩니다. 즉, 모든 Fluid 서비스에 공통 인증 테마가 있지만 각 서비스에 대한 세부 정보 및 사양이 달라집니다.
Azure Fluid Relay 서비스
만든 각 Azure Fluid Relay 서비스 테넌트에는 테넌트 ID와 고유한 테넌트 비밀 키가 할당됩니다.
비밀 키는 공유 비밀입니다. 앱/서비스는 이를 알고 있으며 Azure Fluid Relay 서비스도 이를 알고 있습니다. 테넌트 비밀 키는 테넌트에 고유하게 연결되어 있으므로 이를 사용하여 요청에 서명하면 Azure Fluid Relay 서비스에 대한 요청이 테넌트의 권한 있는 사용자로부터 온다는 것을 보장합니다.
비밀 키는 Azure Fluid Relay 서비스가 앱 또는 서비스에서 요청이 온다는 것을 아는 방법입니다. 이는 Azure Fluid Relay 서비스가 요청을 하는 사용자의 앱임을 신뢰할 수 있게 되면 사용자가 보내는 데이터를 신뢰할 수 있기 때문에 매우 중요합니다. 이것이 비밀이 안전하게 처리되는 것이 중요한 이유이기도 합니다.
주의
비밀에 대한 액세스 권한이 있는 사용자는 누구나 Azure Fluid Relay 서비스와 통신할 때 애플리케이션을 가장할 수 있습니다.
JSON Web Token 및 Azure Fluid Relay 서비스
Azure Fluid Relay는 JWT(JSON Web Token)를 사용하여 비밀 키로 서명된 데이터를 인코딩하고 확인합니다. JSON Web Token은 권한 및 사용 권한에 대한 추가 정보를 포함할 수 있는 서명된 JSON 비트입니다.
참고 항목
JWT의 세부 정보는 이 문서에서 다루지 않습니다. JWT 표준에 대한 자세한 내용은 JSON Web Token 소개를 참조하세요.
인증 세부 정보는 Fluid 서비스마다 다르지만 항상 몇 가지 값이 있어야 합니다.
- containerId Fluid 서비스는 호출 컨테이너에 해당하는 서비스를 식별하기 위해 컨테이너 ID가 필요합니다. 참고: JWT는 이 필드를 documentId라고 부르지만 Fluid 서비스는 이 필드에 컨테이너 ID가 있어야 합니다.
- tenantId: Azure Fluid Relay 서비스는 테넌트 ID를 사용하여 요청을 인증하는 데 사용할 공유 비밀을 검색합니다.
- 범위: 범위는 호출 컨테이너의 권한을 정의합니다. 범위 필드의 콘텐츠는 유연하므로 고유한 사용자 지정 권한을 만들 수 있습니다.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
사용자 모드는 연결이 읽기 또는 읽기/쓰기 모드인지 여부를 나타냅니다. 이는 AzureAudience의 connections 필드에서 볼 수 있습니다. 토큰 범위 권한은 generateToken 함수 아래의 서버리스 Azure 함수에서 업데이트할 수 있습니다.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
컨테이너 동작 및 모드와 함께 토큰 범위는 다음과 같습니다.
| 토큰 범위 | 내 문서 동작 | 대상 그룹 문서 동작 |
|---|---|---|
| DocRead | 문서를 읽고 씁니다. 문서에 대한 변경 내용은 다른 대상 그룹 문서에 반영되지 않습니다. 모드: 읽기 |
문서를 읽고 씁니다. 다른 대상 그룹 문서에는 변경 내용이 반영되지 않습니다. 모드: 쓰기 |
| DocWrite | 문서를 읽고 씁니다. 변경 내용은 다른 모든 대상 그룹 문서에 반영됩니다. 모드: 쓰기 |
문서를 읽고 씁니다. 변경 내용은 다른 모든 대상 그룹 문서에 반영됩니다. 모드: 쓰기 |
| DocRead, DocWrite | 문서를 읽고 씁니다. 변경 내용은 다른 모든 대상 그룹 문서에 반영됩니다. 모드: 쓰기 |
문서를 읽고 씁니다. 변경 내용은 다른 모든 대상 그룹 문서에 반영됩니다. 모드: 쓰기 |
참고 항목
토큰에는 사용자 정보도 포함되어 있습니다(위의 7-9행 참조). 이를 사용하여 대상 그룹 기능을 사용하여 Fluid 코드에 자동으로 제공되는 사용자 정보를 보강할 수 있습니다. 자세한 내용은 토큰에 사용자 지정 데이터 추가를 참조하세요.
토큰 공급자
Azure Fluid Relay에 대한 모든 요청은 유효한 JWT로 서명되어야 합니다. Fluid는 이러한 토큰을 만들고 서명하는 책임을 토큰 공급자에게 위임합니다.
토큰 공급자는 @fluidframework/azure-client가 Azure Fluid Relay 서비스에 요청하는 데 사용하는 토큰을 만들고 서명하는 일을 담당합니다. 자체 보안 토큰 공급자 구현을 제공해야 합니다. 그러나 Fluid는 테넌트 비밀을 허용하는 InsecureTokenProvider를 제공한 다음 서명된 토큰을 로컬에서 생성하고 반환합니다. 이 토큰 공급자는 테스트에 유용하지만 프로덕션 시나리오에서는 사용할 수 없습니다.
안전한 서버리스 토큰 공급자
보안 토큰 공급자를 빌드하기 위한 한 가지 옵션은 서버리스 Azure 함수를 만들고 이를 토큰 공급자로 노출하는 것입니다. 이렇게 하면 보안 서버에 테넌트 비밀 키를 저장할 수 있습니다. 그런 다음 애플리케이션은 Azure 함수를 호출하여 InsecureTokenProvider처럼 로컬에서 서명하는 대신 토큰을 생성합니다. 자세한 내용은 방법: Azure 함수로 TokenProvider 작성을 참조하세요.
사용자 인증을 Fluid 서비스 인증에 연결
Fluid 서비스는 특정 사용자에게 연결되지 않은 공유 클라이언트 암호를 사용하여 수신 호출을 인증합니다. Fluid 서비스의 세부 정보를 기반으로 사용자 인증을 추가할 수 있습니다.
사용자 인증을 위한 한 가지 간단한 옵션은 단순히 Azure Function을 토큰 공급자로 사용하고 토큰을 가져오기 위한 조건으로 사용자 인증을 적용하는 것입니다. 애플리케이션이 함수를 호출하려고 하면 인증 시스템으로 인증되지 않으면 실패합니다. 예를 들어, Microsoft Entra ID를 사용하는 경우 Azure Function에 대한 Microsoft Entra 애플리케이션을 만들고 이를 조직의 인증 시스템에 연결할 수 있습니다.
이 경우 사용자는 Microsoft Entra ID를 사용하여 애플리케이션에 로그인하고 이를 통해 Azure Function을 호출하는 데 사용할 토큰을 가져옵니다. Azure Function 자체는 동일하게 작동하지만 이제 Microsoft Entra ID로 인증한 사용자만 액세스할 수 있습니다.
이제 Azure 함수는 유효한 토큰을 가져오기 위한 진입점이므로 함수에 대해 적절하게 인증된 사용자만 클라이언트 애플리케이션에서 Azure Fluid Relay 서비스에 해당 토큰을 제공할 수 있습니다. 이 2단계 방식을 사용하면 Azure Fluid Relay 서비스와 함께 고유한 사용자 지정 인증 프로세스를 사용할 수 있습니다.