Jack Henschel's Blog

A Deep Dive into Debugging an Authentik OIDC userinfo error

Posted on
#authentik #oidc #oauth2 #gitea

I’m using Authentik as a single-sign on provider for all applications in my homelab. After a recent upgrade from Authentik to the latest version (2024.12.4 -> 2025.8.4), I was no longer able to log into my Gitea instance. After logging in via OIDC, Gitea simply greeted me with a 500 Internal Server error page. This is the moment every homelabber dreads: an upgrade breaks a critical service and there’s no one to blame but yourself.

Gitea greets me with an Internal Server Error after logging in

This led me onto a debugging journey that lasted several days and I want to share with you in this post.

#  Initial troubleshooting

Given the fact that I had just updated Authentik, the immediate suspicion was of course on Authentik. However, the possibility that Gitea is sending an incorrect (i.e. non-spec compliant) OAuth request to Authentik - which with this recent version of Authentik is no longer tolerated - could not be excluded.

Based on Gitea’s logs, I figured out that Gitea responds with a 500 error because it is not able / not allowed to reach the userinfo OAuth2 endpoint of Authentik:

1

UserSignIn: OAuth2 Authentik responded with a 403 trying to fetch user information

Based on past experience I know that 403 Forbidden errors are common in an OAuth2 setup when the access token does not have the correct scope, namely it’s missing the openid scope which allows the access token to retrieve additional details about the user itself from the identity provider (IdP).

Then I checked the Authentik logs and found:

1

{"auth_via": "unauthenticated", "domain_url": "auth.example.com", "event": "Scope mismatch.", "host": "auth.example.com", "level": "warning", "logger": "authentik.providers.oauth2.utils", "pid": 47, "request_id": "48043a09d93d4ae7b04069696044db74", "required": "{'openid'}", "schema_name": "public", "timestamp": "2025-10-08T07:04:56.733333", "token_has": "set()"}

Simplified:

1
2
3

event: "Scope mismatch"
required: "{'openid'}"
token_has: "set()"

Indeed it seems that the token sent by Gitea does not have a scope set! But why should that be the case all of a sudden? I was deeply skeptical at this point, so I pulled out the big guns: tcpdump + Wireshark.

1
2

ssh cubieserver
tcpdump -w /tmp/gitea-login.pcap -i any "(host <GITEA_POD_IP> and port 3000) or (host <AUTHENTIK_POD_IP> and port 9000)"

Let me quickly explain the command:

  • -i any: This tells tcpdump to listen on all network interfaces. In a Kubernetes or container environment with virtual networking, this is a lifesaver because you don’t have to guess which specific virtual interface the pod’s traffic is using.
  • "(host ... or host ...)": This filter is the most important part. It captures only the traffic to and from the Gitea and Authentik pods on their respective ports, saving me from having to sift through tons of unrelated network noise.
  • -w /tmp/gitea-login.pcap: I’m writing the output to a .pcap file so I can open it in a powerful tool like Wireshark for detailed analysis later, which is much easier than trying to read the stream in the terminal.
  • In my homelab, I terminate TLS at the ingress controller. This means traffic from the outside world is encrypted, but once it enters my cluster network, communication between services is plain, which makes debugging in situation like these much easier.

Wireshark screenshot showing analysis of tcpdump packet capture

Indeed with this additional insight I could check the entire authentication flow and confirm that the access token returned by Authentik does not have the required - in fact it has no scopes at all - despite Gitea requesting the openid email profile scopes.

1
2
3
4
5
6
7

{
  "access_token": "eyJhbG....",
  "token_type": "Bearer",
  "scope": "",
  "expires_in": 3600,
  "id_token": "eyJhb..."
}

What the hell?

#  Bug report

At this point I was pretty convinced that this must be a bug in the version of Authentik. But despite spending hourse going through the changelogs of several versions, the bug tracker as well as pull requests I couldn’t find any hint that the OIDC behavior was recently changed (deliberately or accidentally). I also couldn’t find any meaningful results on the web when searching for “authentik userinfo 403 Forbidden insufficient scope” or “authentik returns oauth token without scope”. Surely someone else would have run into this issue before with such a common scenario (OAuth2 access tokens used for the userinfo endpoint)?

I decided to put together a small reproducer using oidc-demo-client app:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# config.yaml
auth_method: client_secret_basic
client_id: 7VqFxp...
client_secret: ZbvrEc...
scopes:
  - openid
  - profile
  - email
token_signing_alg:
  - "RS256"
token_encryption_alg:
## RSA
- RSA-OAEP
- RSA-OAEP-256
## Eliptic curve
- ECDH-ES
- ECDH-ES+A128KW
- ECDH-ES+A192KW
- ECDH-ES+A256KW
issuer: "https://auth.example.com/application/o/gitea2/"

Then run the demo client and log in via browser:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

$ oidc-client client -c config.yaml

2025-10-08T09:04:34.484+0200 [INFO]  oidc-client: oidc-client:
  version=
  | 0.22.0
  | commit: 5feb965
  | built at: 2025-01-25T15:42:17Z
  | built by: goreleaser
  | goos: darwin
  | goarch: arm64

2025-10-08T09:04:35.575+0200 [INFO]  oidc-client: OIDC Client:
  Config=
  | ClientID: 7VqFxpMB7B8OANhVLJqmzSYo64qYEmMVM9rEFjaJ
  | Client_Secret: ************
  | Redirect_Uri: http://127.0.0.1:5556/auth/callback
  | Scopes: openid,profile,email
  | Issuer: https://auth.example.com/application/o/gitea2/

  Advanced=
  | AcrValues:
  | TokenEndpoint:
  | AuthorizeEndpoint:
  | TokenSigningAlg: [RS256]
  | SkipTLSVerification: false
  | JwksEndpoint:

  Validation=
  | AmrWhitelist: []
  | AcrWhitelist: []

2025-10-08T09:04:35.576+0200 [INFO]  oidc-client: Go to http://127.0.0.1:5556/login
2025-10-08T09:04:54.289+0200 [INFO]  oidc-client: Received AuthZ Code: code=4a5f688cd4214847bdae5484195ff6f6
2025-10-08T09:04:55.467+0200 [INFO]  oidc-client: AccessToken expiration: exp="2025-10-08 09:09:55.467535 +0200 CEST m=+320.986051584"
2025-10-08T09:04:55.467+0200 [INFO]  oidc-client: Access Token Response:
  Response=
  | {
  |     "access_token": "eyJhbGciOi....",
  |     "token_type": "Bearer",
  |     "scope": "",
  |     "expires_in": 300,
  |     "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImZlOG..."
  | }

2025-10-08T09:04:56.553+0200 [INFO]  oidc-client: IDToken Claims:
  header=
  | {
  |     "alg": "RS256",
  |     "kid": "fe8fec7095cf2a72b3c8fc0c1b18bdaa",
  |     "typ": "JWT"
  | }

  IDTokenClaims=
  | {
  |     "iss": "https://auth.example.com/application/o/gitea2/",
  |     "sub": "655fb2799e69cc37a9b41feb75bfed3ec508566c06f89e0fbff3786a205532f5",
  |     "aud": "7VqFxpMB7B8OANhVLJqmzSYo64qYEmMVM9rEFjaJ",
  |     "exp": 1759907394,
  |     "iat": 1759907094,
  |     "auth_time": 1759848605,
  |     "acr": "goauthentik.io/providers/oauth2/default",
  |     "amr": [
  |         "pwd"
  |     ],
  |     "nonce": "BQjKrw2U-aQ6Ttd_",
  |     "sid": "dfb4e0da9bfed1dd2351815d581595a20f0f09826a172b512a703c9a56122355"
  | }

2025-10-08T09:04:56.716+0200 [ERROR] oidc-client: http error: response_headers="map[Content-Type:[text/html; charset=utf-8] Date:[Wed, 08 Oct 2025 07:04:54 GMT] Referrer-Policy:[same-origin] Vary:[Accept-Encoding Cookie] Www-Authenticate:[error=\"insufficient_scope\", error_description=\"The request requires higher privileges than provided by the access token\"] X-Authentik-Id:[48043a09d93d4ae7b04069696044db74] X-Content-Type-Options:[nosniff] X-Frame-Options:[DENY] X-Powered-By:[authentik]]" response_body="\"\""

Just like Gitea before, oidc-client receives a 403 Forbidden response from the userinfo endpoint with the error message: error="insufficient_scope", error_description="The request requires higher privileges than provided by the access token.

So it clearly must be a bug in Authentik!

#  AI analysis

Since I had already put together all the evidence (including logs from Gitea and Authentik), I decided to feed it to the AI (Gemini 2.5 Pro in this case). And the result surprised me!

Can you help me troubleshoot this issue with Oauth2 / OIDC? (all the context from before)

Root cause

The key to understanding the problem lies in this line from your Authentik server logs:

1
2
3
4
5
6
7
8

{
    "auth_via": "session",
    "event": "Application requested scopes not configured, setting to overlap",
    "level": "info",
    "logger": "authentik.providers.oauth2.views.authorize",
    "scope_allowed": "set()",
    "scope_given": "{'profile', 'email', 'openid'}"
}

This log entry shows that your application correctly requested the openid, profile, and email scopes (scope_given). However, Authentik’s configuration for this provider has no allowed scopes defined (scope_allowed": "set()").

Solution

To fix this, you need to explicitly add the required scopes to your OAuth2 Provider in Authentik.

  • Navigate to your Authentik Admin Interface.
  • Go to Applications -> Providers.
  • Click on the OAuth2 Provider you are using for this application (e.g., gitea2).
  • Under the Advanced protocol settings section, locate the Scopes field.
  • From the dropdown list, select the scopes your application needs, such as openid, profile, and email.
  • Click Update to save the changes.

Okay, I already knew before that something was off with the scopes. But Gemini correctly pointed me in the direction of Authentik’s OAuth2 provider configuration for scopes, which should look like this:

working scopes

but mine looked like this:

missing scopes

Hummm, there are no scopes selected for this provider, but I don’t even have any scopes available? That certainly explains why the access token does not have any scope assigned to it. While the Authentik UI only showed an empty list of property mapppings, the logs revealed that something deeper was broken: an exception by the name of NotImplementedError (again helpfully spotted by Gemini after I gave it a whole lot of the Authentik’s JSON logs).

1
2
3

{"auth_via": "session", "domain_url": "auth.cubieserver.de", "event": "Task enqueued", "host": "auth.cubieserver.de", "level": "info", "logger": "authentik.tasks.middleware", "pid": 46, "request_id": "d9dee574e052499290f6c852a8120bef", "schema_name": "public", "task_id": "9586406a-18ac-4539-a9ca-37f8f9cdf9a7", "task_name": "authentik.events.tasks.event_trigger_dispatch", "timestamp": "2025-10-08T07:51:38.919246"}
{"event": "Internal Server Error: /api/v3/propertymappings/all/", "exception": [{"exc_notes": [], "exc_type": "NotImplementedError", "exc_value": "", "exceptions": [], "frames": [{"filename": "/ak-root/.venv/lib/python3.13/site-packages/asgiref/sync.py", "lineno": 489, "name": "thread_handler"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/core/handlers/exception.py", "lineno": 42, "name": "inner"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/asgiref/sync.py", "lineno": 489, "name": "thread_handler"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/core/handlers/base.py", "lineno": 253, "name": "_get_response_async"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/asgiref/sync.py", "lineno": 439, "name": "__call__"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/asgiref/current_thread_executor.py", "lineno": 40, "name": "run"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/asgiref/sync.py", "lineno": 493, "name": "thread_handler"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/views/decorators/csrf.py", "lineno": 65, "name": "_view_wrapper"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/viewsets.py", "lineno": 125, "name": "view"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/views.py", "lineno": 515, "name": "dispatch"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/views.py", "lineno": 475, "name": "handle_exception"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/views.py", "lineno": 486, "name": "raise_uncaught_exception"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/views.py", "lineno": 512, "name": "dispatch"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/mixins.py", "lineno": 43, "name": "list"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/serializers.py", "lineno": 797, "name": "data"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/serializers.py", "lineno": 251, "name": "data"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/serializers.py", "lineno": 716, "name": "to_representation"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/serializers.py", "lineno": 540, "name": "to_representation"}, {"filename": "/ak-root/.venv/lib/python3.13/site-packages/rest_framework/fields.py", "lineno": 1870, "name": "to_representation"}, {"filename": "/authentik/core/api/property_mappings.py", "lineno": 55, "name": "get_component"}, {"filename": "/authentik/core/models.py", "lineno": 1017, "name": "component"}], "is_cause": false, "is_group": false, "syntax_error": null}], "level": "error", "logger": "django.request", "timestamp": "2025-10-08T07:51:38.926489"}
{"auth_via": "session", "domain_url": "auth.cubieserver.de", "event": "/api/v3/propertymappings/all/?managed__isnull=true&ordering=name&page=1&page_size=20&search=", "host": "auth.cubieserver.de", "level": "info","logger": "authentik.asgi", "method": "GET", "pid": 46, "remote": "10.42.1.22", "request_id": "d9dee574e052499290f6c852a8120bef", "runtime": 241, "schema_name": "public", "scheme": "https", "status": 500, "timestamp": "2025-10-08T07:51:38.932822", "user": "akadmin", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:140.0) Gecko/20100101 Firefox/140.0"}

My best guess is that the Authentik upgrade process included a database migration to move from these old “legacy” mapping types to a new system. For some reason, that migration either failed to run or didn’t complete successfully on my instance, leaving the database in this inconsistent state. This would explain why the UI couldn’t even render the list of available scopes.

Gemini then recommended me to remove the faulty property mapping using the Django shell. However, before I do that I wanted to check how many of the property mappings might be problematic. This took a couple of prompts and back and forth with Gemini, but in the end it managed to produce a working script that I executed as follows:

1
2

kubectl -n authentik exec -it deploy/authentik-server -- sh
./manage.py shell

the script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

from authentik.core.models import PropertyMapping

print("Starting direct check of all Property Mappings...")
print("="*60)

found_issues = False
all_mappings = PropertyMapping.objects.all()

for pm in all_mappings:
    try:
        # This is the most direct test of the failing condition.
        # It will access the property exactly as the server does.
        _ = pm.component
    except NotImplementedError:
        print(f"[!! LEGACY MAPPING FOUND !!]")
        print(f"  ID (PK): {pm.pk}")
        print(f"  Name: '{pm.name}'")
        print("    ^-- This mapping's type is not implemented and must be deleted.")
        found_issues = True
    except Exception as e:
        # Catch any other potential errors
        print(f"[?? UNEXPECTED ERROR ON MAPPING ??]")
        print(f"  ID (PK): {pm.pk}")
        print(f"  Name: '{pm.name}'")
        print(f"    ^-- Encountered an error: {type(e).__name__} - {e}")
        found_issues = True

print("="*60)
if found_issues:
    print("Check complete. Found the problematic mapping(s).")
else:
    print("Check complete. No faulty mappings were found.")

Unfortunately it turned out that all the property mappings were somehow broken:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148

[!! LEGACY MAPPING FOUND !!]
  ID (PK): 5a702c6f-4dc2-48ee-b6ad-47f4cb42dcb7
  Name: 'OIDC-Scope-minio'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 78fc14da-ed12-4679-86fe-c95f9a4a1890
  Name: 'authentik default SAML Mapping: Groups'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 917deb5c-b826-41d3-9414-de6239994c4f
  Name: 'authentik default SAML Mapping: WindowsAccountname (Username)'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): d3485549-09b0-4bb1-8e7d-c4441b06ddd7
  Name: 'authentik default SAML Mapping: UPN'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 6a1811e8-cb3c-4dfb-8bc7-54e18748f75e
  Name: 'authentik default SAML Mapping: Name'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): e8153e01-b6cc-43e5-89bf-d913231e399b
  Name: 'authentik default SAML Mapping: Email'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 715055cf-863f-4d31-bbe0-878ce74d673b
  Name: 'authentik default SAML Mapping: Username'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): c07e87f4-29f9-4473-b65f-b4d064ee5f32
  Name: 'authentik default SAML Mapping: User ID'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 97585436-c194-4eff-888b-d33589d0005e
  Name: 'authentik default OAuth Mapping: OpenID 'openid''
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 5c891898-d502-4d5f-9fa4-ad7556de2be8
  Name: 'authentik default OAuth Mapping: OpenID 'email''
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 3ff3608b-65ed-4530-a90a-f13ace7323af
  Name: 'authentik default OAuth Mapping: OpenID 'profile''
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 43936fca-2da2-47af-ac9c-497c610ab25d
  Name: 'authentik default OAuth Mapping: Proxy outpost'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): d119fb66-9cc3-47e2-a45c-4c1d8300fff6
  Name: 'authentik default OAuth Mapping: Application Entitlements'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 078c63e3-de56-41a6-a9ab-4183b5580dec
  Name: 'authentik default OAuth Mapping: OpenID 'offline_access''
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): f9960c6e-9086-4a07-919a-517642d2ee9f
  Name: 'authentik default OAuth Mapping: authentik API access'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 59f547fb-4f3f-4f7b-a566-1a53876a5257
  Name: 'authentik default LDAP Mapping: DN to User Path'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 0068b103-19f7-4cbe-99a2-e1ff74f1c708
  Name: 'authentik default LDAP Mapping: Name'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 95d59a4e-3d82-40be-8f2c-1afa0ff97816
  Name: 'authentik default LDAP Mapping: mail'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): f95c13a5-8d77-4935-871d-219ca9fc8682
  Name: 'authentik default Google Workspace Mapping: Group'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 7ce9acbb-a633-4519-81de-866be25a6dce
  Name: 'authentik default Active Directory Mapping: sAMAccountName'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): e1dd9367-81f5-45c1-9952-3f864b14b395
  Name: 'authentik default SCIM Mapping: Group'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): e8b4f942-2661-45e8-82c0-e4573a2e28d0
  Name: 'authentik default Active Directory Mapping: userPrincipalName'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): d102c9c7-22fc-43ed-8b7f-a181a60e04eb
  Name: 'authentik default Active Directory Mapping: givenName'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 36b929b1-f3bb-4588-8691-c2847f67f118
  Name: 'authentik default Active Directory Mapping: sn'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 1e68184b-2730-4f26-8a87-e51788b68ee2
  Name: 'authentik default Kerberos User Mapping: Multipart principals as service accounts'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): c59cd375-d7b0-4501-b9d6-cb7b6195de43
  Name: 'authentik default Kerberos User Mapping: Ignore other realms'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 61ac09ab-7b7d-4cdc-b115-1782754aff3c
  Name: 'authentik default Kerberos User Mapping: Ignore system principals'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): e4039b3f-fcfc-4a82-8c4a-e5cac269cce8
  Name: 'authentik default Microsoft Entra Mapping: Group'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 8b95ee69-a0b2-4bc1-a3db-83680da2bbd6
  Name: 'authentik default Google Workspace Mapping: User'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 87c23587-42f0-4410-ba60-b521d35225c1
  Name: 'authentik default Kerberos User Mapping: Add realm as group'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 911e151a-c5e3-48c5-9638-12470fd2c10d
  Name: 'authentik default Microsoft Entra Mapping: User'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 5f60bad6-ec2e-4b39-ae6c-68d5394d0ad0
  Name: 'authentik default RAC Mapping: RDP Default settings'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 3bb98ac5-209b-415c-95c0-150685d08031
  Name: 'authentik default RAC Mapping: RDP High Fidelity'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 470dbcee-03f5-40a2-8544-950cd7276714
  Name: 'authentik default RAC Mapping: SSH Default settings'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): 5222b536-938e-4ccc-92b0-9e828ea6dea6
  Name: 'authentik default SCIM Mapping: User'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): d21b6b15-5783-4b8c-b428-4c1328f71221
  Name: 'authentik default OpenLDAP Mapping: uid'
    ^-- This mapping's type is not implemented and must be deleted.
[!! LEGACY MAPPING FOUND !!]
  ID (PK): f3186f84-3085-43f9-8311-4ad6ff5cdac6
  Name: 'authentik default OpenLDAP Mapping: cn'
    ^-- This mapping's type is not implemented and must be deleted.

That’s great, just great! /s

Gemini insisted that it was safe to delete these property mappings since they are “legacy”, but I wasn’t so sure about that and how I could get them back in case I needed them.

Gemini telling me to delete the legacy property mappings

At the same time, I had a database backup and the database seemed to be in an inconsistent state already, so how much worse could it get by deleting a couple of entries? Gemini suggested to run the following script in the Authentik / Django shell (honestly quite impressive that it can come up with this stuff out of nowhere!) and it worked on the first try.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

from authentik.core.models import PropertyMapping

# List of all identified legacy mapping Primary Keys (PKs)
pks_to_delete = [
    '5a702c6f-4dc2-48ee-b6ad-47f4cb42dcb7', '78fc14da-ed12-4679-86fe-c95f9a4a1890',
    '917deb5c-b826-41d3-9414-de6239994c4f', 'd3485549-09b0-4bb1-8e7d-c4441b06ddd7',
    '6a1811e8-cb3c-4dfb-8bc7-54e18748f75e', 'e8153e01-b6cc-43e5-89bf-d913231e399b',
    '715055cf-863f-4d31-bbe0-878ce74d673b', 'c07e87f4-29f9-4473-b65f-b4d064ee5f32',
    '97585436-c194-4eff-888b-d33589d0005e', '5c891898-d502-4d5f-9fa4-ad7556de2be8',
    '3ff3608b-65ed-4530-a90a-f13ace7323af', '43936fca-2da2-47af-ac9c-497c610ab25d',
    'd119fb66-9cc3-47e2-a45c-4c1d8300fff6', '078c63e3-de56-41a6-a9ab-4183b5580dec',
    'f9960c6e-9086-4a07-919a-517642d2ee9f', '59f547fb-4f3f-4f7b-a566-1a53876a5257',
    '0068b103-19f7-4cbe-99a2-e1ff74f1c708', '95d59a4e-3d82-40be-8f2c-1afa0ff97816',
    'f95c13a5-8d77-4935-871d-219ca9fc8682', '7ce9acbb-a633-4519-81de-866be25a6dce',
    'e1dd9367-81f5-45c1-9952-3f864b14b395', 'e8b4f942-2661-45e8-82c0-e4573a2e28d0',
    'd102c9c7-22fc-43ed-8b7f-a181a60e04eb', '36b929b1-f3bb-4588-8691-c2847f67f118',
    '1e68184b-2730-4f26-8a87-e51788b68ee2', 'c59cd375-d7b0-4501-b9d6-cb7b6195de43',
    '61ac09ab-7b7d-4cdc-b115-1782754aff3c', 'e4039b3f-fcfc-4a82-8c4a-e5cac269cce8',
    '8b95ee69-a0b2-4bc1-a3db-83680da2bbd6', '87c23587-42f0-4410-ba60-b521d35225c1',
    '911e151a-c5e3-48c5-9638-12470fd2c10d', '5f60bad6-ec2e-4b39-ae6c-68d5394d0ad0',
    '3bb98ac5-209b-415c-95c0-150685d08031', '470dbcee-03f5-40a2-8544-950cd7276714',
    '5222b536-938e-4ccc-92b0-9e828ea6dea6', 'd21b6b15-5783-4b8c-b428-4c1328f71221',
    'f3186f84-3085-43f9-8311-4ad6ff5cdac6',
]

# Find all mappings with a PK in the list
queryset = PropertyMapping.objects.filter(pk__in=pks_to_delete)
count = queryset.count()

if count > 0:
    print(f"Found {count} legacy mappings to delete. Deleting now...")
    # Delete them all at once
    deleted_info = queryset.delete()
    print(f"Deletion complete. Result: {deleted_info}")
else:
    print("No legacy mappings from the list were found.")

At this point I noticed in the Authentik web UI that a couple of the Blueprints (specifically the ones related to authentication providers) had failed to execute after the last upgrade. The error message was a bit cryptic, but seemed to point to the property mappings issue we cleaned up just now, so I re-ran those blueprints by clicking on the “Play” button. This time all of them executed successfully.

authentik blueprints

I check back in the Authentik Oauth2 provider configuration, and now I could finally select the correct scopes for the application!

selected scopes

At last I could log in to Gitea again!

#  Conclusion

Well, this was a long and winding post, but I hope you learned something in the process.

Personally, I have two takeaways from this odyssey:

  • Always feed your bug reports (including all relevant context) to an AI. If you’ve put enough information together that another human can understand it, it’s definitely worth it to let the AI have a crack at it. In fact, this file was originally called authentik-bug-report.md!
  • Check your Authentik Blueprints after each upgrade to make sure they ran successfully as they may give you a clue if anything went wrong during the upgrade or migration process.

Happy debugging!

#  Resources