How to enable Microsoft oauth using Azure EntraID?

[ikke-t]

Hi,

I've been miserably failing while trying to setup ms oauth. I hope someone points my error. So I did the following:

1. Go to registerd apps

2. and selected the new registration from top,

I use the below selection to do SPA and trying by giving it all the auth methods. I use the callback url from librebooking; https://my.librebookin.com/Web/microsoft-auth.php

3. Add new app

I get the ClientID from here.

4. Create secret:

I get the secret ID from here.

5. I copy the client ID and Secret ID to librebooking settings along with the tenant id.

This gives me the MS login button at LB login. I get through the MS login path, and it throws me back to LB with firefox console having this error message from MS:

Proof Key for Code Exchange is required for cross-origin authorization code redemption.

What do I do wrong here?

My app is hosted in kubernetes from librebooking container via http. It has cloudflared in front publishing the application as http/https in public domain name. This is just a test setup while I figure out if LB is good for me or not. If we decide using it, it goes directly to some internet hosting with no cloudflared. But I don't think this should make a difference.

For reference, the google auth worked immediately.

[JohnVillalovos]

Here is what various AI tools said. I would like to be able to answer this myself but I have zero experience with this. I have only used LDAP.

So takes these answers with a lot of skepticism

Gemini's response

Issue Summary

The user is attempting to set up Microsoft OAuth for a LibreBooking instance hosted on Kubernetes (behind a Cloudflare tunnel). They have successfully configured Google Auth, but Microsoft Auth is failing.

• Setup: Azure App Registration configured as a Single Page Application (SPA).
• Redirect URI: https://my.librebookin.com/Web/microsoft-auth.php.
• The Error: Proof Key for Code Exchange is required for cross-origin authorization code redemption.

The Root Cause

The error occurs because the user chose the SPA platform in Azure EntraID.

1. SPA vs. Web: In Azure, an "SPA" registration is designed for frontend-only apps (like React or Vue) and strictly mandates PKCE (Proof Key for Code Exchange). It usually doesn't use a Client Secret.
2. LibreBooking Logic: LibreBooking is a PHP-based application. Its authentication flow happens on the server-side (at the /Web/microsoft-auth.php endpoint). This requires a standard Web platform registration, which uses a Client Secret to exchange the authorization code for a token.

---

Recommended Fix

The user needs to change the platform type in the Azure Portal:

1. Navigate to the App Registration in the Azure Portal.
2. Go to the Authentication tab.
3. Delete the "Single-page application" platform configuration.
4. Click Add a platform and select Web.
5. Enter the Redirect URI: https://my.librebookin.com/Web/microsoft-auth.php.
6. Ensure Implicit Grant settings (Access tokens/ID tokens) are left unchecked, as LibreBooking uses the Authorization Code Flow.
7. Save and test the login again.

ChatGPT's response

Root cause

You registered the Azure/Entra application as an SPA (Single-Page Application), but LibreBooking performs a server-side OAuth authorization code exchange using the PHP endpoint Web/microsoft-auth.php.

Microsoft treats SPA redirects as public clients and requires PKCE. LibreBooking’s current PHP flow likely does not send PKCE, so Microsoft returns:

"Proof Key for Code Exchange is required for cross-origin authorization code redemption"

This is a configuration mismatch, not a bug in LibreBooking.

---

Recommended Fix (most common solution)

Change the app from SPA → Web

In Microsoft Entra:

App registrations → Your app → Authentication

1. Under Platform configurations:
   • Remove the "Single-page application (SPA)" redirect
2. Click "Add a platform"
3. Choose "Web"
4. Add redirect URI:
   https://your.librebooking.host/Web/microsoft-auth.php
5. Save

---

Why this works

Type: SPA
Intended for: browser JavaScript apps
PKCE required: Yes

Type: Web
Intended for: server apps (PHP/Node/etc)
PKCE required: No

LibreBooking is a PHP server app, so it must be registered as Web.

---

Very common second mistake

Use Client Secret VALUE, not Secret ID.

In Entra → Certificates & Secrets → Client secrets:

• Secret ID → do NOT use
• Value → paste this into LibreBooking

If you paste the Secret ID, token exchange fails.

---

Sanity checklist

Before testing again:

[ ] Platform is Web
[ ] Redirect exactly matches https://host/Web/microsoft-auth.php
[ ] HTTPS only
[ ] Client secret is VALUE
[ ] Tenant ID correct
[ ] No SPA platform entries remain

---

When would you actually need PKCE?

Only if you intentionally want:

• tokens handled entirely in the browser
• no backend secret
• true SPA flow

Then LibreBooking would need code changes to add:

• code_challenge
• code_verifier

For a PHP backend, this is unnecessary.

---

TL;DR

Switch SPA → Web and use the secret VALUE.

That should immediately resolve the error.

Claude's response

The issue is that you've registered the app as a SPA (Single Page Application) in Azure, but LibreBooking is a server-side PHP application that needs a Web app registration instead.

Solution: Change Azure App Registration Type

1. Go back to your app registration in Azure Portal

• Navigate to your LibreBooking app registration

2. Remove the SPA platform configuration

• Go to Authentication section
• Under "Single-page application", remove the redirect URI you added

3. Add a Web platform instead

• Click "Add a platform"
• Select "Web" (NOT "Single-page application")
• Add your redirect URI: https://my.librebookin.com/Web/microsoft-auth.php
• Important: Under "Implicit grant and hybrid flows", you likely don't need to check anything (leave both unchecked unless LibreBooking docs say otherwise)
• Click Configure

4. Verify your Client Secret is still valid

• The client secret you created should work with the Web platform

Why this fixes it

• SPA apps in Azure require PKCE (Proof Key for Code Exchange) because they run in the browser and can't securely store secrets
• Web apps are for server-side applications (like PHP) that can securely store client secrets and use the traditional OAuth authorization code flow
• LibreBooking's PHP backend expects the Web flow, not the SPA flow

Alternative Checks

If you want to keep troubleshooting, you could also check:

• Make sure your Redirect URI in Azure exactly matches what LibreBooking is using (no trailing slashes, correct https/http)
• Verify the Tenant ID is correct (you can use common, organizations, or your specific tenant ID)

---

Note: Since Google OAuth worked immediately for you, this strongly suggests the app registration type is the issue - Google's setup probably defaulted to the right configuration.

[ikke-t]

Thanks for the tips. I went back to SPA -> Web. This also goes through the MS auth process, but now fails at LB end:

[2026-02-08T19:48:07.459687+00:00] app.ERROR: [User=  ()] Uncaught exception: GuzzleHttp\Exception\ClientException: Client error: `POST https://login.microsoftonline.com/823acc54-a9c5-4cd4-91b6-3f9699d3b47e/oauth2/v2.0/token` resulted in a `401 Unauthorized` response: {"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret provided. Ensure the secret being se (truncated...)  

I checked, the client ID, tenant ID and secret ID are the same as in azure portal.

[ikke-t]

And now by setting secret value instaed of secret id, I get further with auth. Like if it went through, but email not found:

[2026-02-08T19:53:12.625747+00:00] app.ERROR: [User=  ()] Uncaught exception: Exception: There was an error executing your query\nColumn 'email' cannot be null in /var/www/html/lib/Database/MySQL/MySqlConnection.php:119 S

[JohnVillalovos]

Here are some responses.

Gemini

The AADSTS7000215 error almost always points to one of three specific issues with how the secret is handled between Azure and your LibreBooking configuration.

1. Secret Value vs. Secret ID (Most Common)

In the Azure Portal, under Certificates & secrets, you will see two columns: Value and Secret ID.

• Secret ID: This is just a unique identifier for the secret object (a GUID). It is not the password.
• Value: This is the actual string (e.g., 8q7~...) that must be used in the LibreBooking configuration.

Note: The Value is only visible immediately after you create the secret. If you didn't copy it then, it will be masked (e.g., *********), and you must create a New client secret to get a new value.

2. Kubernetes Secret Escaping

Since you mentioned your app is hosted in Kubernetes, how are you passing the secret?

• Environment Variables: If you are passing the secret via a yaml file or a .env file and the secret contains special characters (like $, &, or *), Kubernetes or the shell might be attempting to interpolate them as variables.
• Base64 Encoding: If you are using a Kind: Secret in K8s, ensure the value is correctly base64 encoded without trailing newlines. You can verify this by running:

  echo -n "YOUR_SECRET_VALUE" | base64

3. URL Encoding / Special Characters

Azure secrets often contain characters like +, /, or =. If LibreBooking's internal Guzzle client doesn't handle the encoding correctly, or if the secret is being truncated in the configuration file, the authentication will fail.

• Try generating a new secret. If the new secret contains a character that looks problematic (like a backslash or a leading dash), delete it and generate another one until you get a "cleaner" alphanumeric string.

4. "Web" Redirect URI Mismatch

Since you switched from SPA to Web, ensure that the Redirect URI is explicitly listed under the Web platform section in Azure.

• If you left the URI in the SPA section and added a new Web section without the URI, the token exchange will fail because the "Client Type" and "Redirect URI" must match the platform registration.

---

Next Step to Debug:
If you are certain the Value is correct, try to manually exchange the code for a token using curl from inside one of your pods to see the full error message from Microsoft:

curl -X POST [https://login.microsoftonline.com/](https://login.microsoftonline.com/)[TENANT_ID]/oauth2/v2.0/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=[CLIENT_ID]" \
-d "scope=openid profile email" \
-d "code=[AUTHORIZATION_CODE_FROM_URL]" \
-d "redirect_uri=[https://my.librebookin.com/Web/microsoft-auth.php](https://my.librebookin.com/Web/microsoft-auth.php)" \
-d "grant_type=authorization_code" \
-d "client_secret=[SECRET_VALUE]"

If this returns the same 401, the issue is definitely the client_secret string itself.

ChatGPT

That AADSTS7000215: Invalid client secret provided is very specific: Microsoft is telling you the secret you’re sending in the token request is not a valid client secret for that app. In almost every case, this is because you’re using the Secret ID instead of the Secret Value (or the value has expired / belongs to a different app).

The key point

In Entra → Certificates & secrets → Client secrets, each secret has two identifiers:

• Secret ID → an identifier (not usable as the secret)
• Value → the actual secret string you must paste into LibreBooking

LibreBooking needs the Value. If you paste the Secret ID, you’ll get exactly the 401 invalid_client you’re seeing.

---

What to do

1) Create a new client secret and copy the Value

Because Microsoft only shows the secret value once:

1. Entra Admin Center → App registrations → your app
2. Certificates & secrets → Client secrets → New client secret
3. Set an expiration you’re comfortable with (e.g., 6/12/24 months)
4. Immediately copy the “Value” (not Secret ID)
5. Paste that value into LibreBooking as the client secret

---

2) Confirm you’re editing the correct app registration

It’s easy to copy a client ID from one app and a secret from another.

Make sure:

• The Application (client) ID in Entra matches LibreBooking
• The secret you created is under that same app registration
• The Directory (tenant) ID matches the tenant in the token URL (yours does: .../823acc54-.../oauth2/v2.0/token)

---

3) Watch for “secret got mangled” issues

A surprising number of failures come from copy/paste problems:

• trailing spaces
• newline at end
• quoting it in config when you shouldn’t
• YAML/env-var escaping if you’re deploying via Kubernetes/Helm

If you’re storing it in a Kubernetes Secret, double-check you didn’t accidentally base64 the wrong field, or include quotes in the literal.

---

4) If you’re using a certificate-based credential (rare)

If you configured the app to use a certificate rather than a client secret, then you can’t use client_secret at all. But your error indicates LibreBooking is sending client_secret, so you should have a valid secret value.

---

Quick “this is the mistake” litmus test

You wrote:

“client ID, tenant ID and secret ID are the same as in azure portal.”

That strongly suggests you are indeed using the Secret ID field. The fix is: use the Secret VALUE (and usually generate a new one so you can copy it cleanly).

---

If you paste (redacting the secret) the snippet of LibreBooking config where you set Microsoft OAuth, I can point out exactly where the secret should go and what formatting to avoid (especially if it’s coming from env vars / Helm).

Claude

Ah! The issue is likely that you're using the Secret ID instead of the Secret Value. This is a very common mistake!

The Problem

When you create a client secret in Azure, you get two different values:

• Secret ID - This is a UUID/GUID that identifies the secret (looks like: 12345678-1234-1234-1234-123456789abc)
• Secret Value - This is the actual secret string you need to use in LibreBooking

You need to use the Secret Value, not the Secret ID.

How to Fix It

Option 1: If you still have the secret value visible

When you first created the secret, Azure showed you the Value column. You need to copy that value (it's usually a long random string).

⚠️ Important: Azure only shows the secret value once when you create it!

Option 2: If you didn't save the secret value

If you didn't copy the secret value when you created it, you'll need to:

1. Go back to Certificates & secrets in your Azure app registration
2. Delete the old secret (or just leave it)
3. Click "New client secret"
4. Give it a description and expiration
5. Click Add
6. Immediately copy the VALUE (not the Secret ID)
7. Paste this value into LibreBooking settings

Additional Checks

• Make sure there are no extra spaces before/after the secret when you paste it
• The secret value is case-sensitive
• Make sure the secret hasn't expired

[ikke-t]

it fails getting email:

[2026-02-08T19:59:46.700613+00:00] sql.ERROR: [User= ()] MySql Query: SELECT * FROM users WHERE ( (username IS NOT NULL AND username = null) OR (email IS NOT NULL AND email = null) ); [] []

It gets name from MS, but not email

[2026-02-08T19:59:46.724144+00:00] sql.ERROR: [User= ()] MySql Execute: INSERT INTO users (email, password, fname, lname, phone, organization, position, username, salt, timezone, language, homepageid, status_id, date_created, public_id, default_schedule_id, terms_date_accepted) VALUES (null, '4cfb...numbers', 'Frist', 'Surname, null, null, null, null, '2aa4a1b7', 'Europe/Helsinki', 'en_us', '1', '2', '2026-02-08 19:59:46', null, null, null); [] []

Sounds like it fails to get email, and tries to create a new user without email. Two problems here, why does it fail getting email, and second, LB has a bug trying to create user with no email.

[JohnVillalovos]

Gemini

Nice! Getting the name means the handshake is working—now we just have to fix the "identity crisis" where Azure is being stingy with the email address.

The SQL error shows that email and username are coming through as null. This usually happens because the Scopes (permissions) or the ID Token claims aren't configured to include the email address.

Here are the three things you need to check in the Azure Portal:

---

1. Check API Permissions (Scopes)

LibreBooking needs the right scopes to ask Microsoft for the email.

1. Go to API permissions in your App Registration.
2. Ensure you have email, openid, and profile (all under Microsoft Graph) added as Delegated permissions.
3. Crucial: Even if they are added, click "Grant admin consent for [Your Org]" at the bottom of that table to ensure they are fully active.

2. Check Optional Claims (The "Email" toggle)

By default, Azure doesn't always include the email in the token even if you have the permission.

1. Go to Token configuration in the sidebar.
2. Click Add optional claim.
3. Select ID as the token type.
4. Check the box for email.
5. Click Add. (It might ask you to turn on the "Microsoft Graph email permission"—say yes).

3. Ensure the User actually has an Email field

In EntraID, check the user profile you are testing with.

• Make sure the Mail property is filled out.
• If the user only has a User Principal Name (UPN) and no actual "Mail" attribute set, Microsoft sometimes sends the UPN instead of an email, which LibreBooking might not be looking for.

---

Why the SQL Failed

Looking at your log:
WHERE ( (usernameIS NOT NULL ANDusername = null) OR (emailIS NOT NULL ANDemail = null) )

LibreBooking is trying to find an existing user to "match" the login, but since Microsoft sent null, it's looking for a user where the email is null. When it fails to find one, it tries to INSERT a new user with null values, which likely violates your database constraints.

Next step: Try adding the Optional Claim for email first. That is the most common reason the "Name" arrives but the "Email" stays empty.

ChatGPT

You’re past OAuth now — the remaining problem is simply that LibreBooking is not receiving an “email” value from Microsoft, so it ends up querying/inserting with null:

• Query shows username = null and email = null
• Insert shows email = null and username = null, while fname/lname are populated

That means the Microsoft user profile response LibreBooking is parsing contains a name but not an email-like field (or LB is looking at the wrong field).

Why email is often missing with Entra ID

For Entra ID users, an email can be absent for several valid reasons:

1. The user object has no mail set
   In many tenants, users don’t have the mail attribute populated unless they have Exchange Online / a mailbox, or it’s been explicitly set.

2. LibreBooking is reading mail, but your tenant only has userPrincipalName (UPN)
   A very common case is:

   • mail = null
   • userPrincipalName = user@domain.tld (which is what you want to treat as the email for login)

3. Permissions/scopes don’t include what LB uses to fetch the profile
   If LB is calling Microsoft Graph /me, it typically needs at least User.Read (delegated). If it’s using OIDC claims only, it needs openid profile email, and the tenant/app must actually emit an email claim.

What to check in Entra (fastest path)

1) Verify the user actually has an email-like attribute

In Entra Admin Center:

• Users → pick the user → look at:
  • Mail
  • User principal name

If Mail is empty but User principal name looks like an email, then LibreBooking needs to use UPN as fallback.

2) Confirm delegated Graph permissions + consent

App registrations → your app → API permissions:

• Ensure you have Microsoft Graph → Delegated → User.Read
• Then click Grant admin consent (or ensure each user can consent)

If LB’s Graph call lacks permission, you’d usually see a Graph 401/403 in logs — but it’s still worth confirming.

3) Add/emit the right claim (optional claims)

If LibreBooking is relying on ID token claims instead of Graph:
App registrations → your app → Token configuration:

• Add optional claims for ID token / access token such as:
  • email (if available in tenant)
  • preferred_username
  • upn / userPrincipalName (depends on what Entra offers in that blade)

Even with optional claims, if the directory doesn’t have an email, email can still come back empty — so fallback logic is still best.

What to change in LibreBooking (practical fix)

LibreBooking should not assume mail exists. It should pick the first non-empty value from something like:

• mail
• userPrincipalName
• preferred_username
• (last resort) something stable like the OID, but LB likely expects an email/username

So the mapping should be roughly:

email = mail ?? userPrincipalName ?? preferred_username

And it should refuse login (with a clear error) if all are empty, rather than inserting a user with null email.

The SQL you pasted also reveals a separate bug

This query is wrong SQL logic:

username = null or email = null should be IS NULL, not = null.

So LB is probably building a query with a bound parameter that is NULL and then comparing with = which will never match.

That doesn’t cause the “missing email” — but it does mean LB won’t find an existing user if the identifier is null, and then it inserts a broken user record.

Suggested next steps

1. In Entra, check whether the user has mail populated.
2. If mail is empty, decide what you want LB to use:
   • Prefer userPrincipalName as the “email/username”
3. In LibreBooking code, update the Microsoft profile parsing to use fallback fields.
4. Add a guard: if email is still empty, stop and show an error like:
   “Microsoft did not return an email/UPN; please ensure the account has an email address or configure fallback to UPN.”

If you paste the section of LibreBooking that parses the Microsoft user info (or point me to the exact file/function in the repo you’re running), I can suggest the precise patch (a few lines) to implement the fallback cleanly.

Claude

Great progress! Now the issue is that LibreBooking isn't receiving the email address from Microsoft. This is because you need to grant the correct API permissions in Azure.

The Problem

Microsoft OAuth isn't returning the email address because the app doesn't have permission to read it. The logs show:

• username = null
• email = null

Solution: Add API Permissions in Azure

1. Go to your app registration in Azure Portal

2. Navigate to "API permissions"

• Click on "API permissions" in the left menu

3. Add the required Microsoft Graph permissions

• Click "Add a permission"
• Select "Microsoft Graph"
• Select "Delegated permissions"
• Add these permissions:
  • User.Read (should already be there by default)
  • email
  • profile
  • openid

4. Grant admin consent (if required)

• If you see a warning about admin consent, click "Grant admin consent for [your organization]"
• Confirm the action

5. Verify the permissions

Your API permissions should look like:

• Microsoft Graph - Delegated:
  • email
  • openid
  • profile
  • User.Read

Alternative: Check the Scope Parameter

If the permissions are already added, LibreBooking might not be requesting them in the OAuth flow. The application should request these scopes:

openid profile email User.Read

You may need to check LibreBooking's Microsoft OAuth configuration to ensure it's requesting these scopes.

After Making Changes

1. Save the changes in Azure
2. Log out of LibreBooking
3. Clear your browser cache/cookies for the LibreBooking site
4. Try authenticating again with Microsoft

The email should now be passed to LibreBooking and the user creation should succeed.

[ikke-t]

OK, some success. So turns out I got it working for the account I use azure with by doing the above instructed:

1. Allowed more API permissions to allow all openid, profile, email, User.Read. Also pressed the grand for org.
2. Allowed Token permissions ID -> email
3. At this point I found out the azure profile primary email was not set, even there was email in profile.

Now it started to work for that account. I dunno if 1 and 2 steps were necessary.

Then I tried with another account of mine. It stopped due user not in tenant.

Then I changed ms.tenant to common in LB. I tried my work account email, creating the user first into LB. This again has the same problem of not getting email. I assume I can't tell all the MS users to go and check their settings in azure, and users likely could not change the api&token perms anyhow. And it would be too complicated.

So I assume this feature is useless outside of some corporate use where org admin can do the above settings.