---
title: "Frequently Asked Questions (FAQ)"
manual: "Azure Login"
version: "4.0"
permalink: "https://docs.typo3.org/permalink/oliverkroener/ok-azure-login:faq@4.0"
source: "Faq.rst"
rendered: "2026-11-02T01:10:24+00:00"
---

# Frequently Asked Questions (FAQ) {#faq}

**How do I install this extension?**

See chapter [Installation](https://docs.typo3.org/permalink/oliverkroener/ok-azure-login:installation@4.0).

**Do users need to exist in TYPO3 before they can log in?**

Yes. The extension matches the authenticated Microsoft account to an
existing `fe_users` or `be_users` record by **email address**. If
no matching record is found, the login is rejected. The extension does
not create new user accounts automatically.

**The backend login error message does not appear**

The backend remembers the login provider you picked in the
`be_lastLoginProvider` cookie, which TYPO3 sets with
`SameSite=Strict`. A browser withholds a Strict cookie on a redirect
chain that started on another site - which is exactly what an OAuth
callback is - so the login screen falls back to whichever provider
sorts first, and that template cannot render `azure_login_error`.

The extension therefore pins `loginProvider=azure-login` on its error
redirects. This matters as soon as a second SSO extension is installed:
`ok_keycloak` registers its provider at the same `sorting` value, so
without the pin which template renders comes down to package order.

**Can I use this for both frontend and backend login?**

Yes. For **frontend login**, add the **Azure Login** content element to a
page. For **backend login**, the extension automatically adds a "Sign in
with Microsoft" tab to the TYPO3 backend login screen. The frontend
redirect URI must be configured manually. The backend redirect URI is
auto-generated and can be copied from the backend configuration module.
Both URIs must be registered in Microsoft Entra ID.

**Which Microsoft Graph API permissions are needed?**

The extension requires **delegated** permissions only: `openid`,
`profile`, and `User.Read`. No application permissions are needed.
See the [Azure Entra ID setup](https://docs.typo3.org/permalink/oliverkroener/ok-azure-login:azure@4.0) for details.

**Where do I configure the Azure credentials?**

The recommended method is the **backend module** at
**Web** \> **Azure Login**. This allows per-site
configuration with encrypted client secret storage.

As a fallback, global credentials can be set via
**Admin Tools** \> **Settings** \>
**Extension Configuration** \> **ok_azure_login**.

See chapter [Configuration](https://docs.typo3.org/permalink/oliverkroener/ok-azure-login:configuration@4.0).

**Can I use different Azure credentials per site?**

Yes. The backend module stores configuration per TYPO3 site root page.
Click on any page belonging to a site in the page tree, and the module
resolves the correct site automatically. Each site can have its own
Tenant ID, Client ID, Client Secret, and frontend redirect URI.
The backend redirect URI is auto-generated from the route configuration.

**How is the client secret stored?**

When configured via the backend module, the client secret is encrypted
using PHP Sodium (`sodium_crypto_secretbox`) before being stored in the
database. The encryption key is derived from TYPO3's
`$GLOBALS['TYPO3_CONF_VARS']['SYS']['encryptionKey']`.

The secret is never displayed in the backend module after saving.

> [!WARNING]
> If the TYPO3 encryption key is not set, the backend module shows a
> warning. Secrets stored via Extension Configuration (fallback) are
> **not** encrypted.

**Where can I get help?**

See chapter [Where to get help](https://docs.typo3.org/permalink/oliverkroener/ok-azure-login:help@4.0).