# SSO Login Fails with “You are not allowed to log in with SSO. Please contact your administrator or supervisor.” – CHT v4.20.0, Azure AD

**URL:** <https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080>\
**Category:** Technical Support\
**Created:** [June 19, 2025, 10:53am UTC](https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080 "2025-06-19T10:53:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kenyuri](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/kenyuri/32/3365_2.png) [@Kenyuri](https://forum.communityhealthtoolkit.org/u/Kenyuri)\
**Post date:** [June 19, 2025, 10:53am UTC](https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080/1 "2025-06-19T10:53:06Z")

</div>

Hello Team,

We are encountering an issue while trying to log in via SSO using Microsoft Azure AD on our **CHT instance (v4.20.0)**  
When attempting to log in with SSO, users see the error message:

 ![image](https://communityhealthtoolkit.b-cdn.net/uploads/default/original/2X/c/cf604952c3c83e57ed94cf288b3fac7872ac6454.png)

On the backend, the logs show:

```auto
'content-type': 'application/json',
date: 'Thu, 19 Jun 2025 10:48:29 GMT',
server: 'CouchDB/3.4.2 (Erlang OTP/25)',
'www-authenticate': 'Basic realm="administrator"',
'x-couch-request-id': '35cf70c0f7',
'x-couchdb-body-time': '0'
},
ok: false
}
}
2025-06-19T10:48:29.390 ERROR: Error logging in via SSO: Error: Error getting authCtx
at unauthorizedError (/service/api/src/controllers/login.js:202:17)
at getUserCtxRetry (/service/api/src/controllers/login.js:294:11)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async oidcLogin (/service/api/src/controllers/login.js:571:23) {
[stack]: [Getter/Setter],
[message]: 'Error getting authCtx',
status: 401
}
2025-06-19T10:48:29.391 RES: 8f2e1a6645a6 10.17.8.66 - GET /medic/login/oidc?code=1.ATAANFOKnnxJik2nl3mXz4zHY8vQmoofaetKvjiScJHD9g9DAQAwAA.AgABBAIAAABVrSpeuWamRam2jAF1XRQEAwDs_wUA9P-W5ULZ0dSxt4hV0zlJ_82hOSA5BlzS8ldHwK6SKhGKpA5yS_i6_v_g_Sd5cQBA3dzsQOGyoaVkSxgVaKlzYe06TxMWxjkxlnIWBsXsXlf0Ae8_97a6BBsnY9MyTQ6BMVRkOBAgQGv9CFlY7zG1zI4TdPt8S8AyE8n_W-rXsR8zONjnHQ9d4L80inPitHDAWBjVk0kZGiZPQDn0MysV8xxfuBxdilVPZP-RCS-647ZzgCbCrf5GLGJJik8gQJ18T09r6P9Kk6q0DhPrpQrzn1I-l88xoFgQNReoxPB5ak5x8rbGLVR0o4zmXaXtXWu8mtB9A7FS5xzdLwK2-lYFv3Fv6A4KwavvbJKYZfKvljywfuKuMOrm6c0am6VsZ-I_58N01O94CmBG_o-5onhAJ8A43hromImvu-n9vod2au-9H_L-gXR-wBWN33Xc2c214MYIMFzVUTlfOFZar1hyQZRZgGgMNgMLuu9xAw4atDnbqVum5YvIi2zcDalaNcYfxWB32_1J0-90PWFu7sl436EWoDjDhVw_Ckk201lNLuAoOvyqbA8t4w0N7jPmoCzDOGCAmW_c2zlEy1yuPijXEvzFE0iWdgs9tKgZX5GOecJBzUBiaFHA2PErMaemjukhIqCpC_N5fCRfE0J_LuIebfxnmMXd_xc57sC31lIZVDA3wc_a3idfMAnjYpx1NdoU4EFBNIlw3HCKCU2lsLDexGnrF_Zyl1Y&session_state=005e7b99-7f1a-5b60-f01f-2d45bffd54b5 HTTP/1.1 302 66 561.168 ms
2025-06-19T10:48:29.578 REQ: b4eed8429d5e 10.17.8.66 - GET /medic/login?sso_error=ssouserinvalid HTTP/1.1
2025-06-19T10:48:29.613 RES: b4eed8429d5e 10.17.8.66 - GET /medic/login?sso_error=ssouserinvalid HTTP/1.1 304 - 33.605 ms

```

Here is the relevant section from our base\_settings;

```auto
"app_url": "<https://url>",
  "oidc_provider": {
    "discovery_url": "https://login.microsoftonline.com/<tenent_id>/v2.0/.well-known/openid-configuration",
    "client_id": "<client_id>"
  }

```

Sample User Document (in CouchDB)

```auto
{
  "_id": "org.couchdb.user:testsso",
  "_rev": "1-bcffafc917a579a1251e30b534a8507e",
  "password_scheme": "pbkdf2",
  "pbkdf2_prf": "sha256",
  "salt": "8aa59f94700f0d5f8d506ac58e4d8611",
  "iterations": 600000,
  "derived_key": "e5e5a11fadc7407a9055de3d1208fccd9e3fa9c28d04cac44ce329887726e0b3",
  "name": "testsso",
  "type": "user",
  "password_change_required": false,
  "roles": [
    "chw"
  ],
  "oidc_username": "raphaelkenyuri@gmail.com",
  "facility_id": [
    "b86793d3-4ea8-4721-99ab-5ef0fbc773f1"
  ],
  "contact_id": "d5788548-d23f-4c82-b924-4676b6ca3d2f"
}

```

Please help on resolving this.

---

<div class="post-metadata">

**Author:** ![bernard](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/bernard/32/88_2.png) [@bernard](https://forum.communityhealthtoolkit.org/u/bernard)\
**Post date:** [June 19, 2025, 7:48pm UTC](https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080/2 "2025-06-19T19:48:35Z")

</div>

Some additional notes.

Instance is running a vanilla CouchDB (not CHT couch). Same app config & cht version runs ok in a different instance running the CHT CouchDB. Both are same CouchDB release version.

Double confirmed that everything SSO config is ok:-

- client secret set
- instance set up for SSO
- user configured for SSO ok

The error occurs when `getting authCtx` using the session cookie that is generated in code.

```auto
const options = { headers: { Cookie: sessionCookie } };
const userCtx = await getUserCtxRetry(options);
const redirectUrl = await redirectToApp({ req, res, sessionCookie, userCtx });

```

This points to a difference in how vanilla CouchDB handles the session cookie generated in code. The [design settled on a couch generation mechanism](https://docs.google.com/document/d/1LUn1ZRetAmYE04CtdcTmp-bEBvl37AZ0CvFXZChXqfU/edit?tab=t.0#heading=h.2xi31l59zwbn) whose risk of breaking is controlled by always deploying the CHT CouchDB.

The solution is to switch to using CHT CouchDB. It might be worth exploring what config differences exist between the vanilla CouchDB and the CHT CouchDB for possible workarounds but I do not believe this is a path that would be supported officially.

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [June 20, 2025, 1:45pm UTC](https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080/3 "2025-06-20T13:45:53Z")

</div>

> [@bernard](#):
>
> This points to a difference in how vanilla CouchDB handles the session cookie generated in code. The [design settled on a couch generation mechanism](https://docs.google.com/document/d/1LUn1ZRetAmYE04CtdcTmp-bEBvl37AZ0CvFXZChXqfU/edit?tab=t.0#heading=h.2xi31l59zwbn) whose risk of breaking is controlled by always deploying the CHT CouchDB.
> 
> The solution is to switch to using CHT CouchDB. It might be worth exploring what config differences exist between the vanilla CouchDB and the CHT CouchDB for possible workarounds but I do not believe this is a path that would be supported officially.

Excellent analysis here @bernard! 👍 I just want to add that this conclusion is not specific to the SSO login functionality, but is universally true for CHT deployments. The only supported version of CouchDB for a CHT deployment is the CHT Couch image specifically packaged for that CHT release. Using any other version of Couch is likely to cause unknown and unintended issues (even when not using SSO login).

The configuration files for the CHT Couch image can be found here: [cht-core/couchdb at master · medic/cht-core · GitHub](https://github.com/medic/cht-core/tree/master/couchdb)

---

<div class="post-metadata">

**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\
**Post date:** [June 23, 2025, 3:53pm UTC](https://forum.communityhealthtoolkit.org/t/sso-login-fails-with-you-are-not-allowed-to-log-in-with-sso-please-contact-your-administrator-or-supervisor-cht-v4-20-0-azure-ad/5080/4 "2025-06-23T15:53:01Z")

</div>

Awesome to see the community helping each other!

I’m seconding Josh’s comment about the CHT’s CouchDB being the only one that is supported. This is an issue that has been [brought up before](https://forum.communityhealthtoolkit.org/t/extending-session-timeout-duration/4794/6), so I wanted to ask: is there a reason that the Medic CouchDB image isn’t used? Is there an improvement we could make that would make CouchDB easier to deploy?
