feat(radius): Android WLAN profile with a per-device app password #1566
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: konairius/homelab#1566
Reference in New Issue
Block a user
Android one-click setup on wlan.renner.uno without a password prompt.
wlan-setup(confidential, authorization code, scopegoauthentik.io/api, redirecthttps://wlan.renner.uno/android/callback). Thedot1x-passwordstage also accepts app passwords (TokenBackend).wlan-setup-oauth(CreatedOnce); the worker reads it for the blueprint, wlan-setup for the code exchange (client_secret_basic)./android/installstarts the authorization;/android/callbackexchanges the code, creates the app passwordwlan-android-<user>-<timestamp>-<random>with the user's own access token and returns the Passpoint profile in the response to that GET. Nothing is stored on the page. Deleting the app password in authentik removes the device.dot1x-app-password-renewon thedot1x-loginbinding renews the app password used for an 802.1X login to 60 days. authentik rejects expired app passwords and deletes them inclean_expired_models.$arg_*(subrequests share the parent's variable cache),proxy_pass_request_headers off,subrequest_output_buffer_size 256k.docs/radius/dot1x.mddescribes the flow and the expiry.🤖 Generated with Claude Code
🤖 Automated review — model
claude-opus-5-5, commitb1be3181efb3fa8a084774653eddbbe911384f1c.Summary
This PR replaces the old flow, where the user typed a password and got a one-time token, with an authorization-code OAuth flow. On the callback, a new authentik app password is created for each Android device and returned straight away in a Passpoint profile.
TokenBackendis added to thedot1x-passwordstage, and a CreatedOnce ESO client secret is added. The design holds up: the state cookie guards against CSRF, the callback checks the username againstX-authentik-username, the access token lasts 5 minutes and stays on the server, and the client secret is alphanumeric, so it fits the$arg_credpath. I found no verified defect. The main risk is in how nginx subrequests handle authentik's responses (see Unverified).mergeableis true, no issue is linked, and no other open PR covers this.⚪ Unverified
wlan-setup-config.yaml:175-183has nosubrequest_output_buffer_size. njs subrequests buffer the reply in memory, and nginx's documented default buffer is 4k or 8k (one memory page). A longer reply gets cut off, so the callback throws and returns 502.GET /api/v3/core/users/me/(passpoint.js,ak(r, "GET", "/api/v3/core/users/me/", …)) returns the session user's groups, avatar (often an initials SVG data URI) andsystem_permissions. For a superuser or a member of many groups, I suspect that is well over 4 KB. I could not check authentik's current response size. Settingsubrequest_output_buffer_size 64k;in the/_aklocation would remove the risk.Accept-Encoding.proxy_pass_request_headersis on by default, so the subrequest sends the browser's headers to authentik-server, apart from the five it overrides. If authentik's server compresses responses when the client sendsAccept-Encoding: gzip,JSON.parse(reply.responseText)will fail on the compressed body. I did not check whether current authentik compresses API responses. Addingproxy_set_header Accept-Encoding "";would be cheap insurance. It would also be cleaner not to forward the gate'sX-authentik-*headers and the browserUser-Agent.POST /api/v3/core/tokens/withintent: app_passwordis called with the user's own token. I did not check whether current authentik lets a user without extra permissions create their own tokens this way. If not, setup works for admins only. The docs only cover the group's maximum lifetime.🟡 Suggestions
wlan-setup-config.yaml(passpoint.jscallback),identifieris built from the username plus a timestamp with one-second resolution. Two installs by the same user in the same second, such as a double tap, use the same identifier, so authentik rejects the second create and the user gets a 502. Adding a few random characters (e.g.random().substring(0, 6)) to the identifier would avoid this.wlan-setup-config.yaml(passpoint.jscallback), each successful callback creates a token that lasts 10 years. If the user cancels the Android installer or opens the link again, the earlier token stays valid and nobody can see it. The page text could tell users to delete unusedwlan-android-*entries in authentik, or the callback could delete older tokens with the same prefix that have never been used.🟢 Nits
wlan-setup-config.yaml:58says "resolved once at start". That is true for upstream blocks, but if the authentik-server Service is ever recreated with a new ClusterIP, wlan-setup has to be restarted. It's fine to leave as is.Tests
The repo has no test harness for these manifests or the njs code. The flow should be tried by hand on Android with a normal (non-admin) user and with an admin user. That would settle the response-size and token-permission questions above.
Recommendation
Looks reasonable — no blocking issues; comments above are optional.
New commits pushed, approval review dismissed automatically according to repository settings
🤖 Automated review — model
claude-opus-5-5, commitc781e263fc81036384b96a6b1a8bca23fe4c8d9c.Summary
Re-review against
b1be318. One commit has landed since then,c781e26. It changes only the/_aklocation and the app-password identifier inwlan-setup-config.yaml. My last review had no 🔴 points. The state of the earlier points:subrequest_output_buffer_size 256kis now set in the/_aklocation.proxy_pass_request_headers offmeans the browser'sAccept-Encoding,User-AgentandX-authentik-*headers no longer reach authentik. Only the explicitly set Host, Cookie, Authorization, Content-Type and Accept headers are sent. nginx's proxy module still adds Content-Length for the POST bodies itself, so that setting does not drop it.random().substring(0, 6), with anything outside[A-Za-z0-9]replaced byx. Every character fits a slug-style identifier and is safe in the/view_key/path.The new changes introduce no defects.
mergeableis true.⚪ Unverified
POST /api/v3/core/tokens/withintent: app_password, using a normal user's own access token. I did not check whether current authentik allows that without extra permissions. A manual Android test with a non-admin account would settle it.Tests
The repo has no test harness for this nginx/njs code. Running the Android flow by hand with a non-admin user would confirm both the buffer fix and the open token-permission question.
Recommendation
Looks reasonable — no blocking issues; comments above are optional. There were no earlier 🔴 points, and the new commit adds none.
New commits pushed, approval review dismissed automatically according to repository settings
🤖 Automated review — model
claude-opus-5-5, commit29da21c28f3ead2f8ee17dc37e82c067ed9c3b20.Summary
This is a re-review against
c781e26. One commit has landed since then,29da21c, and it changes onlydocs/radius/dot1x.md. It changes the stated default cap on app password lifetime from "30 minutes" to "30 days". It names the error that appears when a token's lifetime is over the cap (Token expires exceeds maximum lifetime). It also says outright that creating the app password needs no admin rights. No code or manifest changed. My earlier reviews had no 🔴 points. The state of the earlier points:c781e26and unchanged since.c781e26and unchanged since.c781e26and unchanged since.docs/radius/dot1x.md:168-169), but the PR gives no evidence for it (see below).mergeableis true. There were no author replies or discussion comments to answer.⚪ Unverified
docs/radius/dot1x.md:168-169now says "Creating the app password needs no admin rights." Nothing in this PR backs that up, and I can't check from the repository how current authentik behaves when a normal user callsPOST /api/v3/core/tokens/. A manual Android run with a non-admin account would settle it. If the claim is wrong, Android setup fails with a 502 for normal users.docs/radius/dot1x.md:165says that without the group attribute the cap is 30 days. That is a statement about authentik's current defaults, and I couldn't check it here. It affects only the docs: the setup still needs thedays=3650attribute either way.main. I couldn't list them because no commit-listing tool was available. Sincemergeableis true and the new commit is docs-only, there is no sign of a conflict.Tests
The repo has no test harness for this nginx/njs code. The flow still needs a manual Android test with a non-admin user to confirm the new docs claim about token permissions.
Recommendation
Looks reasonable — no blocking issues; comments above are optional. There were no earlier 🔴 points, and the new commit, which changes only docs, adds none.
New commits pushed, approval review dismissed automatically according to repository settings
🤖 Automated review — model
claude-opus-5-5, commit21625685b4b12079ceb9d14d60b1d4d033bad5e7.Summary
This re-review covers one new commit since
29da21c,2162568. It cuts the lifetime of new app passwords from 10 years to 29 days (LIFETIME_DAYS = 29inpasspoint.js). It adds the expression policydot1x-app-password-renew, bound to thedot1x-loginstage binding withre_evaluate_policies: true, which is meant to extend a used app password to 60 days. It also updates the docs.My earlier reviews had no 🔴 points. State of the earlier points:
c781e26, unchanged since.c781e26, unchanged since.c781e26, unchanged since.The new commit adds no verified defect. Whether the renewal actually fires is uncertain (see Unverified). If it doesn't, every Android device drops off the WLAN after 29 days, and nothing in the logs would show it.
mergeableis true. There are no author replies to answer.⚪ Unverified
request.usermay be the wrong user.blueprints-configmap.yaml:1542filters onuser=request.user. The policy runs when thedot1x-loginbinding is re-evaluated, which is before the user-login stage has signed anyone in. In a re-evaluated stage-binding policy, the policy request's user is probably the HTTP request's user, i.e. anonymous at this point. The identified user would sit in the plan context aspending_user. If so, theupdate()touches zero rows and the token is never renewed.failure_result: trueand the unconditionalreturn True(:1547,:1558) also hide any error.request.userfor re-evaluated binding policies.dot1x-has-vlan(:1567) also usesrequest.user, but it runs as an application policy after authentication, so it does not show what happens here.request.context.get("pending_user"), or drop the user filter. The token pk comes fromTokenBackenditself, so the user filter adds little.:1537-1538assumesTokenBackendstoresauth_method == "token"and a dict withpkunderauth_method_args["token"], and that the re-evaluated policy request includes the plan context. All of this depends on authentik internals (set_method,sanitize_dictandcleanse_dicton a key namedtoken) that I could not read here. If the key is masked or the value is not a dict, the policy silently does nothing.docs/radius/dot1x.md:162).maintouching these files: I could not list them because no commit-listing tool was available.mergeableis true.🟡 Suggestions
blueprints-configmap.yaml:1540-1546: becausefailure_result: truehides errors and a zero-row update is silent, a broken renewal only shows up as devices disconnecting after 29 days. Logging the result ofupdate()withak_logger.info(...)would make the first real 802.1X login with an app password show whether renewal works.Tests
The repo has no test harness for blueprints or njs. Before merging, someone should:
expiresmoved from about 29 to about 60 days.Recommendation
Looks reasonable — no blocking issues; comments above are optional. There were no earlier 🔴 points and the new commit adds none, but the renewal path should be confirmed live before merging.
New commits pushed, approval review dismissed automatically according to repository settings
Answers to the unverified points of review 1929, from authentik
version/2026.8.5:request.userin the renewal policy:authentik/flows/markers.py(ReevaluateMarker.process) builds the engine withPolicyEngine(self.binding, plan.context.get(PLAN_CONTEXT_PENDING_USER, http_request.user))and thenengine.request.context.update(plan.context). The policy sees the pending user, andauth_method/auth_method_argssit at the top level ofrequest.context.auth_method_args.token:TokenBackend.authenticatecallsset_method("token", request, token=token), which storescleanse_dict(sanitize_dict(kwargs))(authentik/core/auth.py).sanitize_itemturns a model intomodel_to_dict={app, model_name, pk, name}with the UUID pk as hex (authentik/events/utils.py).cleanse_itemrecurses into dict values before the key check, so only the inner keys are tested and none of them is masked.claude-bot(is_superuser: false):POST /api/v3/core/tokens/withintent: app_passwordreturned 201,view_key200. A 10-year expiry returned 400Token expires exceeds maximum lifetime(cap now + 30 days), hence the 29-day start.6c2c278(ak_logger.info("dot1x app password", token=..., renewed=count)).