Udostępnij za pośrednictwem

Dostosowywanie logowania i wylogowywanie się w usłudze aplikacja systemu Azure Service

  • Artykuł

W tym artykule pokazano, jak dostosować logowania i wylogowania użytkowników podczas korzystania z wbudowanego uwierzytelniania i autoryzacji w usłudze App Service.

Korzystanie z wielu dostawców logowania

Konfiguracja portalu nie oferuje kluczowego sposobu prezentowania wielu dostawców logowania użytkownikom (takich jak Facebook i X). Jednak dodanie funkcji do aplikacji nie jest trudne. Opisane są następujące kroki:

Najpierw na stronie Uwierzytelnianie/autoryzacja w witrynie Azure Portal skonfiguruj każdego dostawcę tożsamości, który chcesz włączyć.

W obszarze Akcja do wykonania, gdy żądanie nie jest uwierzytelnione, wybierz pozycję Zezwalaj na żądania anonimowe (bez akcji).

Na stronie logowania lub na pasku nawigacyjnym lub w dowolnej innej lokalizacji aplikacji dodaj link logowania do każdego z włączonych dostawców (/.auth/login/<provider>). Na przykład:

<a href="/.auth/login/aad">Log in with Microsoft Entra</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>
<a href="/.auth/login/apple">Log in with Apple</a>

Gdy użytkownik kliknie jeden z linków, zostanie otwarta odpowiednia strona logowania w celu zalogowania się użytkownika.

Aby przekierować użytkownika po zalogowaniu się do niestandardowego adresu URL, użyj parametru post_login_redirect_uri ciągu zapytania (nie należy mylić z identyfikatorem URI przekierowania w konfiguracji dostawcy tożsamości). Aby na przykład przejść do /Home/Index użytkownika po zalogowaniu, użyj następującego kodu HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Logowanie kierowane przez klienta

W przypadku logowania kierowanego przez klienta aplikacja loguje użytkownika do dostawcy tożsamości przy użyciu zestawu SDK specyficznego dla dostawcy. Następnie kod aplikacji przesyła wynikowy token uwierzytelniania do usługi App Service w celu weryfikacji (zobacz Przepływ uwierzytelniania) przy użyciu żądania HTTP POST. Ta walidacja nie zapewnia dostępu do żądanych zasobów aplikacji, ale pomyślna walidacja zapewni token sesji, którego można użyć do uzyskiwania dostępu do zasobów aplikacji.

Aby zweryfikować token dostawcy, aplikacja usługi App Service musi najpierw zostać skonfigurowana przy użyciu żądanego dostawcy. W czasie wykonywania po pobraniu tokenu uwierzytelniania od dostawcy opublikuj token na /.auth/login/<provider> potrzeby weryfikacji. Na przykład:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Format tokenu różni się nieco w zależności od dostawcy. Aby uzyskać szczegółowe informacje, zobacz następującą tabelę:

Wartość dostawcy Wymagane w treści żądania Komentarze
aad {"access_token":"<access_token>"} Właściwości id_token, refresh_tokeni expires_in są opcjonalne.
microsoftaccount {"access_token":"<access_token>"} lub {"authentication_token": "<token>" authentication_token wartość jest preferowana przez access_tokenwartość . Właściwość jest opcjonalna expires_in .
Podczas żądania tokenu z usług na żywo zawsze żądaj wl.basic zakresu.
google {"id_token":"<id_token>"} Właściwość jest opcjonalna authorization_code . authorization_code Podanie wartości spowoduje dodanie tokenu dostępu i tokenu odświeżania do magazynu tokenów. Po określeniu authorization_code redirect_uri można również opcjonalnie dołączyć właściwość .
facebook {"access_token":"<user_access_token>"} Użyj prawidłowego tokenu dostępu użytkownika z serwisu Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Uwaga

Dostawca usługi GitHub na potrzeby uwierzytelniania usługi App Service nie obsługuje dostosowanego logowania i wylogowania.

Jeśli token dostawcy zostanie pomyślnie zweryfikowany, interfejs API zwróci element w authenticationToken treści odpowiedzi, czyli token sesji. Aby uzyskać więcej informacji na temat oświadczeń użytkownika, zobacz Praca z tożsamościami użytkowników w usłudze aplikacja systemu Azure Service.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Po utworzeniu tokenu sesji możesz uzyskać dostęp do chronionych zasobów aplikacji, dodając X-ZUMO-AUTH nagłówek do żądań HTTP. Na przykład:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Wyloguj się z sesji

Użytkownicy mogą zainicjować wylogowywanie, wysyłając GET żądanie do punktu końcowego aplikacji /.auth/logout . Żądanie GET wykonuje następujące czynności:

  • Czyści pliki cookie uwierzytelniania z bieżącej sesji.
  • Usuwa tokeny bieżącego użytkownika z magazynu tokenów.
  • W przypadku firmy Microsoft Entra i Google przeprowadza wylogowywanie po stronie serwera u dostawcy tożsamości.

Oto prosty link na stronie internetowej służący do wylogowywania:

<a href="/.auth/logout">Sign out</a>

Domyślnie pomyślne wylogowanie przekierowuje klienta do adresu URL /.auth/logout/complete. Możesz zmienić stronę przekierowania po wylogowaniu, dodając post_logout_redirect_uri parametr zapytania. Na przykład:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Zaleca się kodowanie wartości post_logout_redirect_uri.

W przypadku korzystania z w pełni kwalifikowanych adresów URL adres URL musi być hostowany w tej samej domenie lub skonfigurowany jako dozwolony zewnętrzny adres URL przekierowania dla aplikacji. W poniższym przykładzie, aby przekierować do https://myexternalurl.com tej domeny, która nie jest hostowana w tej samej domenie:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Uruchom następujące polecenie w usłudze Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Zachowywanie fragmentów adresów URL

Gdy użytkownicy logują się do aplikacji, zazwyczaj chcą zostać przekierowani do tej samej sekcji tej samej strony, takiej jak /wiki/Main_Page#SectionZ. Jednak ponieważ fragmenty adresów URL (na przykład #SectionZ) nigdy nie są wysyłane do serwera, nie są one zachowywane domyślnie po zakończeniu logowania OAuth i przekierowaniu z powrotem do aplikacji. Użytkownicy uzyskują nieoptymalne środowisko, gdy będą musieli ponownie przejść do żądanej kotwicy. To ograniczenie dotyczy wszystkich rozwiązań uwierzytelniania po stronie serwera.

W uwierzytelnianiu usługi App Service można zachować fragmenty adresów URL w ramach logowania OAuth. W tym celu ustaw ustawienie aplikacji o nazwie WEBSITE_AUTH_PRESERVE_URL_FRAGMENT .true Możesz to zrobić w witrynie Azure Portal lub po prostu uruchomić następujące polecenie w usłudze Azure Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Ustawianie wskazówki dotyczącej domeny kont logowania

Zarówno konto Microsoft, jak i usługa Microsoft Entra umożliwiają logowanie się z wielu domen. Na przykład konto Microsoft zezwala na konta outlook.com, live.com i hotmail.com . Firma Microsoft Entra umożliwia dowolną liczbę domen niestandardowych dla kont logowania. Możesz jednak przyspieszyć użytkowników prosto do własnej strony logowania firmy Microsoft Entra (np contoso.com. ). Aby zasugerować nazwę domeny kont logowania, wykonaj następujące kroki.

  1. W pliku w https://resources.azure.comgórnej części strony wybierz pozycję Odczyt/Zapis.

  2. W przeglądarce po lewej stronie przejdź do pozycji subskrypcje><nazwa-subskrypcji>ResourceGroups><resource-group-name providers>Microsoft.Web>sites<>app-name>>>>config>authsettingsV2.

  3. Kliknij przycisk Edytuj.

  4. Dodaj tablicę loginParameters z elementem domain_hint .

    "identityProviders": {
    "azureActiveDirectory": {
        "login": {
            "loginParameters": ["domain_hint=<domain-name>"],
        }
    }
}

  5. Kliknij pozycję Umieść.

To ustawienie dołącza domain_hint parametr ciągu zapytania do adresu URL przekierowania logowania.

Ważne

Klient może usunąć domain_hint parametr po otrzymaniu adresu URL przekierowania, a następnie zalogować się przy użyciu innej domeny. Dlatego chociaż ta funkcja jest wygodna, nie jest to funkcja zabezpieczeń.

Autoryzowanie lub odrzucanie użytkowników

Chociaż usługa App Service zajmuje się najprostszym przypadkiem autoryzacji (tj. odrzucaniem nieuwierzytelnionych żądań), aplikacja może wymagać bardziej szczegółowego zachowania autoryzacji, takiego jak ograniczenie dostępu tylko do określonej grupy użytkowników. W niektórych przypadkach musisz napisać niestandardowy kod aplikacji, aby zezwolić na dostęp do zalogowanego użytkownika lub go zablokować. W innych przypadkach usługa App Service lub dostawca tożsamości mogą być w stanie pomóc bez konieczności wprowadzania zmian w kodzie.

Poziom serwera (tylko aplikacje systemu Windows)

W przypadku dowolnej aplikacji systemu Windows można zdefiniować zachowanie autoryzacji serwera internetowego usług IIS, edytując plik Web.config . Aplikacje systemu Linux nie używają usług IIS i nie można ich skonfigurować za pomocą pliku Web.config.

  1. Przejdź do strony https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. W eksploratorze przeglądarki plików usługi App Service przejdź do witryny/wwwroot. Jeśli plik Web.config nie istnieje, utwórz go, wybierając pozycję+> Nowy plik.

  3. Wybierz ołówek dla pliku Web.config , aby go edytować. Dodaj następujący kod konfiguracji i kliknij przycisk Zapisz. Jeśli plik Web.config już istnieje, wystarczy dodać <authorization> element ze wszystkimi elementami. Dodaj konta, które mają być dozwolone w elemecie <allow> .

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="user1@contoso.com,user2@contoso.com"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Poziom dostawcy tożsamości

Dostawca tożsamości może zapewnić pewną autoryzację klucza zwrotu. Na przykład:

Poziom aplikacji

Jeśli jeden z innych poziomów nie zapewnia wymaganej autoryzacji lub jeśli platforma lub dostawca tożsamości nie jest obsługiwany, musisz napisać kod niestandardowy, aby autoryzować użytkowników na podstawie oświadczeń użytkowników.

Więcej zasobów