fix(authentik): allow authorization_code for matrix-mas (REN-567) #1122

2026-10-04T21:19:27Z

Ghost commented

2026-10-04 21:19:27 +00:00

What

Sets grant_types: [authorization_code, refresh_token] on the Authentik provider Matrix (MAS) (client_id: matrix-mas) in apps/authentik/blueprints-configmap.yaml. That is the only change.

Why

The owner's Authentik login for Matrix fails with "Error from the provider: invalid_request". The logs show the cause:

MAS, 21:10:36Z and 21:13:31Z: GET /upstream/callback/01M4480KWZGN9HBNB5SSNGT2M1 returns 400 Error from the provider: invalid_request, about 90 ms after the authorize redirect, so no login step ran.
Authentik, same request: Invalid grant_type for provider with grant_type=authorization_code, then The request is otherwise malformed.
In Authentik 2026.5.3, OAuth2Provider.grant_types is ArrayField(..., default=list), and views/authorize.py rejects every grant type that is not in that list. A provider created by a blueprint (PR #1121) starts with the list empty. Providers created in the UI get the defaults, which is why the other apps work.

How verified

kustomize build apps/authentik passes.
The blueprint parses; Matrix (MAS) now has grant_types: ['authorization_code', 'refresh_token'].
Live check after merge: an authorize request with client_id=matrix-mas reaches the Authentik login flow instead of redirecting back with error=invalid_request.

Disruption

None. Authentik only re-applies the blueprint, and only this provider changes.

Revert

Revert this commit. Matrix logins through Authentik fail again; password login in MAS still works.

🤖 Generated with Claude Code

## What Sets `grant_types: [authorization_code, refresh_token]` on the Authentik provider `Matrix (MAS)` (`client_id: matrix-mas`) in `apps/authentik/blueprints-configmap.yaml`. That is the only change. ## Why The owner's Authentik login for Matrix fails with "Error from the provider: invalid_request". The logs show the cause: - MAS, 21:10:36Z and 21:13:31Z: `GET /upstream/callback/01M4480KWZGN9HBNB5SSNGT2M1` returns 400 `Error from the provider: invalid_request`, about 90 ms after the authorize redirect, so no login step ran. - Authentik, same request: `Invalid grant_type for provider` with `grant_type=authorization_code`, then `The request is otherwise malformed`. - In Authentik 2026.5.3, `OAuth2Provider.grant_types` is `ArrayField(..., default=list)`, and `views/authorize.py` rejects every grant type that is not in that list. A provider created by a blueprint (PR #1121) starts with the list empty. Providers created in the UI get the defaults, which is why the other apps work. ## How verified - `kustomize build apps/authentik` passes. - The blueprint parses; `Matrix (MAS)` now has `grant_types: ['authorization_code', 'refresh_token']`. - Live check after merge: an authorize request with `client_id=matrix-mas` reaches the Authentik login flow instead of redirecting back with `error=invalid_request`. ## Disruption None. Authentik only re-applies the blueprint, and only this provider changes. ## Revert Revert this commit. Matrix logins through Authentik fail again; password login in MAS still works. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Ghost added 1 commit 2026-10-04 21:19:27 +00:00

fix(authentik): allow authorization_code for matrix-mas (REN-567)

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

e2e45b2b86

Authentik 2026.5 checks each authorize against the provider's
grant_types, and a provider created by a blueprint starts with an empty
list. Every Matrix login through Authentik failed with invalid_request
(log: "Invalid grant_type for provider", grant_type=authorization_code).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Ghost approved these changes

2026-10-04 21:20:50 +00:00

Ghost left a comment

Approved @ e2e45b2b86. Checked: Authentik logs show 'Invalid grant_type for provider' grant_type=authorization_code for client_id=matrix-mas at 21:10:36Z and 21:13:31Z; 2026.5.3 source: grant_types ArrayField default=list, checked in views/authorize.py:184 and views/token.py:168, values 'authorization_code'/'refresh_token' match common/oauth/constants.py. Diff is 7 lines on the Matrix (MAS) provider only, indentation matches siblings. Revert: revert commit.

Approved @ e2e45b2b86e5bf7f60f7482e4c7ec6bf7319c5b8. Checked: Authentik logs show 'Invalid grant_type for provider' grant_type=authorization_code for client_id=matrix-mas at 21:10:36Z and 21:13:31Z; 2026.5.3 source: grant_types ArrayField default=list, checked in views/authorize.py:184 and views/token.py:168, values 'authorization_code'/'refresh_token' match common/oauth/constants.py. Diff is 7 lines on the Matrix (MAS) provider only, indentation matches siblings. Revert: revert commit.

Ghost merged commit c384a052a9 into master

2026-10-04 21:20:51 +00:00

Ghost referenced this issue from a commit

2026-10-04 21:20:53 +00:00

Merge pull request 'fix(authentik): allow authorization_code for matrix-mas (REN-567)' (#1122) from atlas/ren-567-authentik-grant-types into master

review-bot reviewed

2026-10-04 21:22:28 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit e2e45b2b86e5bf7f60f7482e4c7ec6bf7319c5b8.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Single, well-scoped change: adds grant_types: [authorization_code, refresh_token] to the Matrix (MAS) Authentik OAuth2 provider in kubernetes/apps/authentik/blueprints-configmap.yaml (lines 2156-2158), to fix a login failure caused by blueprint-created providers starting with an empty grant_types list. The diff is minimal, matches the PR description, and fits the file's existing conventions.

No blocking issues found.

🟡 Suggestions

kubernetes/apps/authentik/blueprints-configmap.yaml:2152-2155: The new comment explains why the fix is needed (good — matches this file's existing style of detailed inline comments, e.g. the "Matrix (REN-567)" block a few lines above and the k8s-outposts.yaml header comment). One gap: it doesn't say why authorization_code + refresh_token specifically were chosen over the fuller default set a UI-created provider would normally get (e.g. implicit, client_credentials, device_code). For a client_type: public provider with PKCE this is almost certainly the right minimal set, but a one-line note ("MAS only ever uses the auth-code + refresh flow, so no other grant types are needed") would make the intent self-evident to a future reader without needing to re-derive it.
PR body says the changed file is apps/authentik/blueprints-configmap.yaml; the actual path is kubernetes/apps/authentik/blueprints-configmap.yaml. Cosmetic mismatch in the description only, not in the diff itself.

Tests

No automated tests exist for these Authentik blueprint ConfigMaps in this repo (it's a GitOps manifest, validated via kustomize build per the PR's own verification notes), which matches the project's convention for this kind of change — there's nothing to add here. The PR description states manual verification (kustomize build apps/authentik and a live post-merge authorize check); that's consistent with how similar blueprint fixes in this file would normally be validated.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `e2e45b2b86e5bf7f60f7482e4c7ec6bf7319c5b8`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Single, well-scoped change: adds `grant_types: [authorization_code, refresh_token]` to the `Matrix (MAS)` Authentik OAuth2 provider in `kubernetes/apps/authentik/blueprints-configmap.yaml` (lines 2156-2158), to fix a login failure caused by blueprint-created providers starting with an empty `grant_types` list. The diff is minimal, matches the PR description, and fits the file's existing conventions. No blocking issues found. ## 🟡 Suggestions - `kubernetes/apps/authentik/blueprints-configmap.yaml:2152-2155`: The new comment explains *why* the fix is needed (good — matches this file's existing style of detailed inline comments, e.g. the "Matrix (REN-567)" block a few lines above and the `k8s-outposts.yaml` header comment). One gap: it doesn't say why `authorization_code` + `refresh_token` specifically were chosen over the fuller default set a UI-created provider would normally get (e.g. `implicit`, `client_credentials`, `device_code`). For a `client_type: public` provider with PKCE this is almost certainly the right minimal set, but a one-line note ("MAS only ever uses the auth-code + refresh flow, so no other grant types are needed") would make the intent self-evident to a future reader without needing to re-derive it. - PR body says the changed file is `apps/authentik/blueprints-configmap.yaml`; the actual path is `kubernetes/apps/authentik/blueprints-configmap.yaml`. Cosmetic mismatch in the description only, not in the diff itself. ## Tests No automated tests exist for these Authentik blueprint ConfigMaps in this repo (it's a GitOps manifest, validated via `kustomize build` per the PR's own verification notes), which matches the project's convention for this kind of change — there's nothing to add here. The PR description states manual verification (`kustomize build apps/authentik` and a live post-merge authorize check); that's consistent with how similar blueprint fixes in this file would normally be validated. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1122