SharePointMicrosoft Entra IDMigracjaAzure AD

SharePoint ACS zostaje wycofany 2 kwietnia 2026. Oto jak migrować do Entra ID.

Opublikowano · Zaktualizowano · 14 min czytania · Zespół Optymized

Termin: 2 kwietnia 2026

Microsoft całkowicie wycofuje Azure Access Control Service (ACS) dla SharePoint 2 kwietnia 2026. Po tej dacie wszystkie tokeny app-only oparte na ACS przestaną działać. Jeśli Twoje aplikacje używają ACS do dostępu do SharePoint Online, przestaną funkcjonować. Jeśli jeszcze nie migrowałeś, zacznij teraz — pewien przestój może być nieunikniony, ale każdy dzień się liczy.

Zakres tego przewodnika: Ten artykuł dotyczy migracji uwierzytelniania app-only opartego na ACS na Microsoft Entra ID. Pełne wycofanie SharePoint Add-In obejmuje też provider-hosted add-iny z tokenami user+app oraz SharePoint-hosted add-iny (zastępowane przez SPFx). Pełen obraz znajdziesz w oficjalnym ogłoszeniu Microsoft o wycofaniu.

Jeśli rejestrowałeś aplikacje SharePoint przez appregnew.aspx i nadawałeś im uprawnienia przez appinv.aspx, to te aplikacje używają Azure Access Control Service (ACS). Microsoft wyłącza ACS 2 kwietnia 2026 — a jego następcą jest Microsoft Entra ID (dawniej Azure Active Directory).

Od lat migrujemy rozwiązania SharePoint dla klientów enterprise. Ten przewodnik obejmuje wszystko: co się zmienia, dlaczego i dokładnie jak migrować aplikacje na Entra ID.

Czym jest ACS i dlaczego jest wycofywany?

Azure Access Control Service (ACS) to legacy usługa uwierzytelniania, która pozwalała SharePoint Add-ins uzyskiwać tokeny app-only. Jeśli kiedykolwiek używałeś stron SharePoint /_layouts/15/appregnew.aspx do rejestracji aplikacji i /_layouts/15/appinv.aspx do nadania uprawnień, to korzystałeś z ACS.

Ważne: ACS to nie tylko tokeny app-only. Provider-hosted add-iny działające w kontekście użytkownika (tokeny user+app) też przechodzą przez ACS. Jeśli Twoja aplikacja frontendowa przekierowuje użytkowników przez ACS, żeby uzyskać token do SharePoint, ten flow też przestanie działać. Zarówno scenariusze app-only, jak i user+app wymagają migracji.

ACS był standardowym podejściem przez lata. Był prosty: dostawałeś Client ID i Client Secret, a kod używał ich do uzyskiwania tokenów. Problem? ACS to stara, ograniczona usługa:

  • Uprawnienia tylko na cały tenant — nie można ograniczyć dostępu do konkretnych kolekcji witryn
  • Client secret wygasa — a gdy to nastąpi, integracja przestaje działać bez ostrzeżenia
  • Brak audytu — ograniczona widoczność tego, co aplikacja faktycznie robi
  • Brak Conditional Access — nie można zastosować nowoczesnych polityk bezpieczeństwa

Microsoft oficjalnie wycofał ACS jako ogólną usługę Azure jeszcze w listopadzie 2018, ale utrzymywał endpoint ACS specyficzny dla SharePoint (accounts.accesscontrol.windows.net). Ten okres przejściowy kończy się 2 kwietnia 2026.

Co przestanie działać 2 kwietnia 2026

Po dacie wycofania endpoint ACS przestanie wydawać tokeny. To oznacza:

Przestanie działać

  • Aplikacje używające GetACSAppOnlyContext()
  • Azure Functions / WebJobs wywołujące SharePoint przez tokeny ACS
  • Custom connectory Power Automate z danymi ACS
  • Narzędzia firm trzecich skonfigurowane z ACS Client ID + Secret
  • Każdy kod wywołujący TokenHelper.GetAppOnlyAccessToken()
  • Provider-hosted add-iny używające ACS do tokenów user+app (TokenHelper.GetAccessToken())

NIE przestanie działać

  • Aplikacje już używające Microsoft Entra ID
  • Rozwiązania SharePoint Framework (SPFx)
  • Wywołania Microsoft Graph API przez tokeny Entra ID
  • Uwierzytelnianie użytkownika przez MSAL / Entra ID, gdzie żaden element w łańcuchu nie używa ACS do wywołań SharePoint
  • SharePoint webhooks (używają Entra ID)

Jak sprawdzić czy jesteś dotknięty

Uruchom to polecenie PowerShell, aby wylistować wszystkie aplikacje zarejestrowane przez ACS w Twoim tenancie:

# Połącz się z SharePoint Online Management Shell
Connect-SPOService -Url https://twoj-tenant-admin.sharepoint.com

# Wylistuj wszystkie ACS app principals
Get-SPOServicePrincipalPermissionGrant | Format-Table -AutoSize

Jeśli to polecenie zwróci wyniki, te aplikacje muszą być migrowane.

Microsoft Entra ID: następca

Microsoft Entra ID (nowa nazwa Azure Active Directory, czyli Azure AD) to nowoczesna platforma tożsamości dla wszystkich usług Microsoft 365. Zamiast client secretów ACS używasz:

Certyfikaty X.509

Klucz prywatny nigdy nie opuszcza Twojego serwera. Bezpieczniejsze niż współdzielone sekrety.

Granularne uprawnienia

Wybór między Sites.Read.All, Sites.ReadWrite.All, Sites.FullControl.All lub Sites.Selected dla ograniczonego dostępu.

Microsoft Graph

Dostęp do SharePoint przez zunifikowane Microsoft Graph API lub klasyczne SharePoint REST/CSOM.

ACS vs Entra ID — porównanie

ACS (stary)Entra ID (nowy)
UwierzytelnianieClient ID + SecretCertyfikat X.509 (zalecany)
Zakres uprawnieńTylko cały tenantCały tenant lub konkretne witryny
Dostęp do APITylko SharePoint CSOM/RESTMicrosoft Graph + SharePoint REST/CSOM
Audyt / complianceOgraniczonyPełne logi logowania Entra ID
Conditional AccessBrak wsparciaPełne wsparcie
StatusWycofywany 2 kwietnia 2026Aktywny, zalecany

Opcja 1: Automatyczna migracja z PnP PowerShell

Najszybszy sposób rejestracji nowej aplikacji w Entra ID to PnP PowerShell. Jedno polecenie załatwia wszystko: rejestrację aplikacji, tworzenie certyfikatu, upload certyfikatu i konfigurację uprawnień.

Wymaganie: PowerShell 7+

PnP PowerShell wymaga PowerShell 7+ (pwsh). Nie działa na wbudowanym Windows PowerShell 5.1. Zainstaluj go poleceniem winget install Microsoft.PowerShell lub pobierz z dokumentacji Microsoft. Wszystkie poniższe komendy uruchamiaj w pwsh, nie w powershell.exe.

Krok 1: Zainstaluj PnP PowerShell

Install-Module -Name PnP.PowerShell -Scope CurrentUser

Krok 2: Zarejestruj aplikację w Entra ID

$app = Register-PnPAzureADApp \
  -ApplicationName "Nazwa Twojej Aplikacji" \
  -Store CurrentUser \
  -Tenant twojtenant.onmicrosoft.com \
  -Username "admin@twojtenant.onmicrosoft.com" \
  -Password (Read-Host -AsSecureString -Prompt "Podaj hasło") \
  -CertificatePassword (Read-Host -AsSecureString -Prompt "Podaj hasło certyfikatu") \
  -OutPath .\

# Zapisz te wartości — będziesz ich potrzebować w kodzie
$app.'AzureAppId/ClientId'
$app.'Certificate Thumbprint'

To jedno polecenie:

  • Rejestruje aplikację w Entra ID
  • Tworzy certyfikat X.509
  • Importuje certyfikat do magazynu Current User
  • Eksportuje pliki .PFX i .CER do wskazanego folderu
  • Uploaduje klucz publiczny do Entra ID
  • Konfiguruje domyślne uprawnienia (Sites.FullControl.All, User.ReadWrite.All)

Krok 3: Nadaj zgodę admina

Podczas rejestracji pojawi się dialog zgody. Zatwierdź go. Jeśli go przegapisz, wejdź do Azure Portal → Entra ID → Rejestracje aplikacji → Twoja aplikacja → Uprawnienia API → "Udziel zgody administratora."

Dostosuj uprawnienia (opcjonalnie)

# Przykład: tylko Sites.ReadWrite.All zamiast FullControl
Register-PnPAzureADApp \
  -ApplicationName "Nazwa Twojej Aplikacji" \
  -Store CurrentUser \
  -Tenant twojtenant.onmicrosoft.com \
  -Username "admin@twojtenant.onmicrosoft.com" \
  -Password (Read-Host -AsSecureString) \
  -CertificatePassword (Read-Host -AsSecureString) \
  -SharePointApplicationPermissions "Sites.ReadWrite.All" \
  -GraphApplicationPermissions "Sites.ReadWrite.All" \
  -OutPath .\

Opcja 2: Ręczna migracja w Azure Portal

Jeśli potrzebujesz większej kontroli lub Twoja organizacja wymaga ręcznego zatwierdzania każdego kroku, oto proces krok po kroku w Azure Portal.

Krok 1: Zarejestruj aplikację

  1. Wejdź na entra.microsoft.com
  2. Przejdź do TożsamośćAplikacjeRejestracje aplikacji
  3. Kliknij Nowa rejestracja
  4. Wpisz nazwę (np. "Integracja SharePoint - Produkcja")
  5. Wybierz Konta tylko w tym katalogu organizacyjnym (single-tenant)
  6. Kliknij Zarejestruj
  7. Zapisz ID aplikacji (klienta) i ID katalogu (tenanta)

Krok 2: Utwórz i uploaduj certyfikat

Utwórz certyfikat za pomocą PnP PowerShell (lub OpenSSL, lub innego narzędzia):

$cert = New-PnPAzureCertificate \
  -CommonName "certyfikat-twojej-aplikacji" \
  -OutPfx .\twoja-aplikacja.pfx \
  -OutCert .\twoja-aplikacja.cer \
  -ValidYears 2 \
  -CertificatePassword (Read-Host -AsSecureString)

$cert.Thumbprint

Następnie w Azure Portal: Twoja aplikacja → Certyfikaty i sekrety → zakładka CertyfikatyPrzekazywanie certyfikatu → wybierz plik .CER.

Krok 3: Skonfiguruj uprawnienia API

W Azure Portal: Twoja aplikacja → Uprawnienia APIDodaj uprawnienie.

Dla dostępu do SharePoint wybierz Uprawnienia aplikacji (nie delegowane) z:

Microsoft Graph

  • Sites.Read.All
  • Sites.ReadWrite.All
  • Sites.Manage.All
  • Sites.FullControl.All

SharePoint

  • Sites.Read.All
  • Sites.ReadWrite.All
  • Sites.Manage.All
  • Sites.FullControl.All

Krok 4: Nadaj zgodę admina

W sekcji Uprawnienia API kliknij "Udziel zgody administratora dla [Twój tenant]". Kolumna statusu powinna zmienić się na "Udzielono" z zielonym znacznikiem.

Zmiany w kodzie: przed i po

Jeśli używasz PnP Framework (najpopularniejszej biblioteki do SharePoint CSOM), zmiany w kodzie są minimalne. Oto porównanie.

Przed (ACS) — przestaje działać 2 kwietnia 2026

// Uwierzytelnianie ACS — przestanie działać po 2 kwietnia 2026
var am = new AuthenticationManager();

using (var context = am.GetACSAppOnlyContext(
    siteUrl,
    clientId,
    clientSecret))   // <-- współdzielony sekret
{
    var list = context.Web.Lists.GetByTitle("Documents");
    context.Load(list, l => l.Title);
    await context.ExecuteQueryAsync();
    Console.WriteLine(list.Title);
}

Po (Entra ID) — przyszłościowe rozwiązanie

// Uwierzytelnianie Entra ID z certyfikatem X.509
var certificate = X509CertificateUtility.LoadCertificate(
    StoreName.My,
    StoreLocation.CurrentUser,
    certificateThumbprint);  // <-- certyfikat, nie sekret

var am = AuthenticationManager.CreateWithCertificate(
    clientId,
    certificate,
    tenantId);

using (var context = am.GetContext(siteUrl))
{
    // Twój kod CSOM zostaje dokładnie taki sam
    var list = context.Web.Lists.GetByTitle("Documents");
    context.Load(list, l => l.Title);
    await context.ExecuteQueryAsync();
    Console.WriteLine(list.Title);
}

Co się zmieniło?

3 linie

Tylko setup uwierzytelniania się zmienia

0 linii

Logika biznesowa CSOM bez zmian

+1 param

tenantId jest teraz wymagany

Zmiany w konfiguracji

Zaktualizuj ustawienia aplikacji (appsettings.json, zmienne środowiskowe lub Azure Key Vault):

// Przed (ACS)
{
  "SharePoint": {
    "SiteUrl": "https://twojtenant.sharepoint.com/sites/twojawitryna",
    "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "ClientSecret": "twoj-acs-client-secret"
  }
}

// Po (Entra ID)
{
  "SharePoint": {
    "SiteUrl": "https://twojtenant.sharepoint.com/sites/twojawitryna",
    "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "TenantId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
    "CertificateThumbprint": "ABC123DEF456..."
  }
}

Client Secret znika. Zastępuje go Certificate Thumbprint (certyfikat musi być zainstalowany na serwerze z Twoim kodem). Potrzebujesz też Tenant ID.

Checklista migracji

  1. Zinwentaryzuj wszystkie aplikacje ACS — uruchom Get-SPOServicePrincipalPermissionGrant aby znaleźć wszystkie aplikacje korzystające z ACS
  2. Zarejestruj każdą aplikację w Entra ID — użyj PnP PowerShell (szybko) lub Azure Portal (ręcznie)
  3. Utwórz i uploaduj certyfikaty X.509 — jeden na aplikację, z rozsądnym terminem ważności (2 lata to standard)
  4. Skonfiguruj minimalne wymagane uprawnienia — nie używaj FullControl jeśli wystarczy ReadWrite
  5. Nadaj zgodę admina — uprawnienia nie są aktywne póki Global Admin lub Privileged Role Admin nie wyrazi zgody
  6. Zaktualizuj kod — zamień uwierzytelnianie ACS na uwierzytelnianie certyfikatem Entra ID
  7. Wdróż certyfikat — zainstaluj .PFX na wszystkich serwerach/środowiskach z aplikacją
  8. Przetestuj najpierw na tenancie nieprodukcyjnym — zweryfikuj wszystko przed dotykaniem produkcji
  9. Wdróż na produkcję — przed 2 kwietnia 2026
  10. Usuń stare rejestracje ACS — posprzątaj stare app principals, aby zmniejszyć powierzchnię ataku

FAQ

Kiedy SharePoint ACS przestanie działać?

2 kwietnia 2026. Po tej dacie tokeny app-only oparte na ACS nie będą już wydawane. Każda aplikacja polegająca na ACS do dostępu do SharePoint Online natychmiast przestanie działać.

Co zastępuje ACS dla dostępu app-only do SharePoint?

Microsoft Entra ID (dawniej Azure AD). Rejestrujesz aplikację w Entra ID, konfigurujesz certyfikat X.509 do uwierzytelniania i używasz Microsoft Graph lub SharePoint REST API z uprawnieniami aplikacyjnymi.

Czy muszę zmienić kod CSOM?

Tylko część uwierzytelniania. Zamień GetACSAppOnlyContext() na AuthenticationManager.CreateWithCertificate(). Cała logika CSOM (odczyt list, upload plików itp.) zostaje bez zmian.

Czy mogę używać client secret zamiast certyfikatów?

Entra ID obsługuje client secrets w niektórych scenariuszach, ale Microsoft zaleca certyfikaty X.509 dla dostępu app-only do SharePoint Online. Certyfikaty są bezpieczniejsze — klucz prywatny nigdy nie opuszcza serwera.

Czy to wpłynie na SharePoint On-Premise?

Nie. Wycofanie ACS dotyczy tylko SharePoint Online. SharePoint On-Premise (2016, 2019, Subscription Edition) używa własnych mechanizmów uwierzytelniania, które nie są dotknięte.

Potrzebujesz pomocy z migracją?

Termin to 2 kwietnia 2026. Jeśli zaczynasz migrację dopiero teraz, pewien przestój po odcięciu ACS może być nieunikniony — ale im szybciej zaczniesz, tym krótsza przerwa. Od lat migrujemy rozwiązania SharePoint dla klientów enterprise i pomożemy wrócić na właściwe tory jak najszybciej.

Kto za tym stoi

Tomasz Dłuski

Tomasz Dłuski

Założyciel & CEO

Senior Software Engineer z 10+ letnim doświadczeniem. W poprzedniej firmie był częścią firmy, która wyskalowała się z 5 do 50+ inżynierów. Teraz buduje Optymized — firmę, która łączy doświadczenie w dostarczaniu projektów enterprise z własnymi produktami SaaS. Maintainer CRXJS (3.9k stars na GitHubie), jednego z najpopularniejszych narzędzi do budowy rozszerzeń przeglądarek.

Porozmawiajmy o Twoim projekcie

Potrzebujesz rozszerzenia do przeglądarki, dedykowanego zespołu, czy konsultacji technicznej? Znajdźmy najlepsze podejście razem.

lub napisz do nas