The problem, precisely

MCP’s authorization spec builds on OAuth 2.1. Your resource server (the thing serving POST /mcp) points clients at an authorization server, and the client gets a token from it before it’s allowed to call a tool. Nothing unusual so far — except MCP clients are typically dynamic. Claude Code doesn’t ship with a pre-registered client_id for your server; it expects to either:

• register itself on the fly via RFC 7591 Dynamic Client Registration (POST /oauth/register), or
• present a Client ID Metadata Document (CIMD) — an client_id that is itself an https:// URL the authorization server fetches to learn who’s asking.

Authentik supports neither. There’s no registration_endpoint in its discovery document, POST /register doesn’t exist, and CIMD support isn’t there either. This isn’t a config flag you’re missing — goauthentik#8751 has been open since February 2024, milestoned, unshipped. Every OAuth client Authentik can talk to has to be created by hand in its admin UI.

That’s fine for your web app’s login — you register assistant-web once and move on. It’s fatal for MCP, because you don’t control the client. Claude Code tries dynamic registration, finds nothing, and gives up with “Incompatible auth server: does not support dynamic client registration.” There’s a claude mcp add --client-id escape hatch for pre-registered clients, but it’s a dead end too — claude-code#38102, closed as not planned, reports the flag being silently ignored. And even if it worked, “manually register a client per person who wants to connect” is the exact toil DCR exists to avoid.

So: pointing MCP clients at Authentik for a token is a dead end. Something else has to be the authorization server.

The shortcut that looks free, and isn’t

Before building a real authorization server, we considered the cheap version: a thin shim that answers discovery and registration requests itself, but hands off the actual authorization_endpoint and token_endpoint to Authentik. Every client that registers gets mapped onto one pre-provisioned Authentik client under the hood. No new state machine, no token storage, just a translation layer.

It doesn’t survive contact with a conformant client, for a specific and checkable reason. The MCP authorization spec has clients record the issuer from the metadata document they validated, and compare it against the RFC 9207 iss parameter attached to the callback. If your metadata document advertises your own issuer, but Authentik is the one that actually answers the authorization request and stamps the callback, the two iss values never match. Every conformant client rejects the response as a possible mix-up attack; a client that doesn’t check iss accepts it, silently, which is worse.

Fixing that would mean Authentik answering as your issuer — which it can’t — or forwarding requests through in a way that makes the shim not “thin” anymore: a redirect-URI allowlist covering both claude.ai and arbitrary loopback ports, a property mapping to fake an audience per client, and one shared client_id standing in for every distinct caller. At that point you’ve built an authorization server with extra steps and none of the guarantees.

The actual fix: be your own authorization server

The resource server — the thing serving /mcp — becomes the OAuth 2.1 authorization server for its own resource. Authentik keeps doing exactly the one thing it’s good at and nothing more: authenticating the human. It gains no new client, no new provider, no new configuration. If you already run an OIDC backend-for-frontend in front of Authentik for your web login, this slots in beside it rather than replacing anything.

Concretely, that means your API now serves:

• GET /.well-known/oauth-authorization-server (RFC 8414 metadata)
• GET /.well-known/oauth-protected-resource (RFC 9728, unauthenticated by design — it’s how a client with no token yet finds out where to go)
• POST /oauth/register (RFC 7591 DCR) and CIMD support
• GET /oauth/authorize, POST /oauth/token, POST /oauth/revoke (RFC 7009)
• a consent screen, somewhere your frontend owns

The handoff to Authentik happens at exactly one point: GET /oauth/authorize with no existing session redirects into your ordinary login flow — Authentik does its OIDC dance, your callback handler does its usual thing — and then resumes the authorization request it was in the middle of. Authentik never hears the word “MCP.” As far as it’s concerned, a human just logged in.

One wrinkle worth knowing before you hit it: if your callback handler regenerates the session id after login (the standard defence against session fixation — and you should be doing this already), anything you stashed in the session before the login hop is gone when you come back. That’s why the “resume” step can’t rely on session state. Persist the in-flight authorization request as a row — an id round-trips through the login detour just fine even though the session object underneath it gets replaced.

The pieces that actually matter

You don’t need to reimplement all of OAuth from scratch to get this right, but a few decisions are load-bearing and worth making deliberately rather than defaulting into:

Public clients only, PKCE mandatory, no client secret. Every MCP client is either a loopback native app or a browser app; neither can keep a secret, so don’t pretend otherwise by adding a client_secret column you’ll never populate safely. OAuth 2.1 makes PKCE (S256) mandatory for exactly this reason — it’s your actual protection, not the secret you don’t have.

Opaque tokens, hashed, not JWTs. The usual case for signed JWTs is avoiding a database round-trip per request. That case evaporates here: you already need one lookup to turn a token’s subject into a local user, so with your own tokens that same lookup is the verification. What you get back for giving up the “stateless” property is revocation that actually means something — disconnecting a client is an UPDATE, not a denylist — and no JWKS endpoint to stand up, rotate, or back up. Store tokens as SHA-256 digests, never plaintext, so a database dump isn’t a bag of live credentials.

RFC 8707 resource bound into the grant, not just checked once. Validate it on the authorization request, freeze it into the code, bind it into the grant. This is what makes “this token was minted for this MCP server” a fact your resource server can check locally, rather than something it has to trust the identity provider got right — which matters a lot once you’re the one issuing the token in the first place.

A real consent screen, because DCR is unauthenticated by specification. Nothing stops an attacker from registering a client that looks legitimate and points its redirect URI at their own server. The thing that separates a client your user actually wants connected from one an attacker created is a human looking at a screen that says this client, this destination and clicking allow. Don’t skip this because registration already “succeeded” — registration creating a row and a human approving it are different events, and only the second one should unlock a token. Two things are worth not rendering on that screen: a client-supplied logo_uri (an unauthenticated registrant can point it at anything, including content that makes an attacker’s client look like a trusted one), and any of state, code_challenge, or resource — the screen has no use for them, and a value that never reaches the browser can’t be tampered with there.

Loopback redirect-URI matching has to ignore the port, but only there. CLI-style MCP clients bind an ephemeral loopback port every run, and a strict string match will accept exactly one session and reject every one after. OAuth 2.1 §8.4.2 and RFC 8252 §7.3 carve out 127.0.0.1, localhost, and [::1] specifically for this. Scope the exemption tightly — http only, those hosts only, and only the port — because http://127.0.0.1.evil.example/callback is not loopback, and an https redirect never gets this relaxation at all.

Two situations should revoke, not just refuse. A replayed authorization code and a reused (already-rotated) refresh token are both ambiguous: maybe your own client retried after losing a response, maybe someone has a stolen copy. OAuth 2.1 §4.1.3 tells you to assume the worst — kill the whole grant, not just the one bad request. Refusing the replay while leaving the original tokens alive means an attacker who won the race still has something that works.

What we didn’t build, on purpose

Not every gap is worth closing immediately, and it’s worth being explicit about which ones you’re choosing to leave open rather than discovering it later:

• Granular scopes. One scope is enough when authorization is identity-based — a valid token says who you are, and your existing ownership/visibility rules decide what that allows. Scope-gated tools are future work, not a blocker.
• client_credentials. There’s no “client” here without a human behind it; every flow is a person authorizing an app on their own behalf.
• RFC 7592 client management. Optional, and one more near-unauthenticated surface you’d have to defend.
• Forced re-authentication on every /oauth/authorize. Requiring a fresh login every time someone connects a client trades a small security increment for a real amount of friction, and the predictable response to friction is people choosing longer-lived tokens instead — which is worse. Per-client consent is what actually defends against a malicious client; it doesn’t need session age to do that job.

A checklist for your own Authentik instance

If you’re reproducing this shape:

1. Leave Authentik alone. You register one redirect URI there — your app’s normal OIDC callback — and nothing MCP-specific ever gets configured at the IdP. If you find yourself adding an MCP-flavoured client, property mapping, or scope to Authentik, you’ve gone down the shim path above; back out.
2. Your resource server’s canonical URI does double duty: it’s the value clients pass as resource (RFC 8707), it’s what you bind into every grant, and its origin is your new authorization server’s issuer identifier. Derive the issuer from that URI rather than configuring it separately — one source for both, so they can’t drift apart.
3. Verify the two discovery documents first, before you try a real client: /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. A 404 on either, in production, usually means a reverse proxy isn’t routing those paths to your API — it’s indistinguishable from “no authorization server exists” to the client, so it’s the first thing to rule out.
4. Call /mcp with no token and check the 401. The WWW-Authenticate header should name the protected-resource metadata document and a scope — that header is the discovery mechanism, and a client that can’t find it never gets any further.
5. Only then try a real client end to end: register (or present a CIMD), authorize, land on your consent screen, approve, and confirm the redirect carries a code your token endpoint accepts. If step 4 works but this doesn’t, the break is almost always in redirect-URI matching or PKCE verification, not in Authentik.

Authentik is still doing real work in this design — it’s the thing that knows who your users are, and nothing above changes that. It just isn’t, and structurally can’t be, the party that decides what an MCP client is allowed to do on a user’s behalf. Once that split clicks, the rest is a fairly ordinary OAuth 2.1 authorization server, sized to the one resource it exists to protect.

If you are using an HP network scanner on Ubuntu and experiencing unstable behavior during scanning (especially multi-page scans failing partway through), you are not alone.

A common issue with HP LaserJet MFP devices on Linux is that scanning appears to work initially but then fails after several pages. The scanner physically runs, but no output is produced in the software, and the system often only recovers after a reboot.

This article explains the real cause of the problem and how to permanently fix it by switching from the legacy HP driver stack to AirScan.

Symptoms of the Problem

The issue typically looks like this:

• Scanner is correctly detected in Ubuntu
• Single-page scans work normally
• Multi-page scans fail after a few successful pages (often around 8–10)
• The scanner physically scans the document, but no image appears in the application
• Restarting the scanning application does not help
• Only a full system reboot temporarily restores functionality

At first glance, this looks like a network or hardware issue. In reality, it is caused by the scanning backend configuration.

Understanding the Cause

On Ubuntu, HP scanners can be accessed through multiple backends at the same time:

• AirScan (modern eSCL-based network scanning)
• ESCL (raw eSCL interface)
• HPLIP / hpaio (legacy HP scanning backend)

The key issue is that the system may default to using the legacy HPLIP backend even when a modern AirScan interface is available.

The real problem: HPLIP instability

The HP Linux Imaging and Printing system (HPLIP) includes a scanning backend called hp / hpaio. While historically important, it is increasingly problematic for modern network-connected HP devices.

In this case, the issues observed were caused by the HPLIP backend:

• It maintains internal session state across scans
• It can fail after repeated scan jobs
• It may corrupt or lose the image data stream
• It can leave the scanner backend in a broken state until system restart

This explains the key symptom: the scan physically completes, but no data is returned to the system.

Why AirScan Works

AirScan uses the modern eSCL protocol (used by most newer HP network printers). Unlike HPLIP, it works in a much simpler and more reliable way:

• Each scan is stateless
• Communication is handled over standard HTTP
• No persistent session state is required
• No vendor-specific backend logic is involved

Because of this, AirScan avoids the instability seen in the HPLIP stack.

How the Issue Was Diagnosed

The first step was to identify which scanner backends were active:

scanimage -L

This showed multiple available backends, including:

• airscan (eSCL-based)
• escl (raw interface)
• hpaio (HPLIP backend)

To isolate the issue, each backend was tested directly.

AirScan test

scanimage -d airscan:e0:DEVICE_NAME --format=png > test.png

Result: stable and reliable scanning.

HPLIP test

scanimage -d hpaio:... --format=png > test.png

Result: immediate failure or I/O errors.

This confirmed that the issue was not related to the scanner hardware or network, but specifically to the HPLIP backend.

The Fix

The solution was to remove the legacy HP scanning backend and rely exclusively on AirScan.

Step 1: Remove HPLIP scanning components

sudo apt remove hplip libsane-hpaio

Step 2: Verify available scanners

scanimage -L

After removal, only AirScan-based devices should remain.

Step 3: Confirm stable operation

scanimage -d airscan:e0:DEVICE_NAME --format=png > test.png

At this point, scanning becomes stable even for multi-page documents.

Results After Fix

Once the HPLIP backend was removed:

• Multi-page scanning became stable
• No more silent scan failures
• No need to reboot the system
• Ubuntu scanning applications worked normally again
• Only AirScan was used as the scanning backend

Key Takeaways

• Seeing multiple scanner backends in Ubuntu is normal
• The presence of HPLIP does not mean it is the best option
• Modern HP network scanners should use AirScan whenever available
• HPLIP scanning backend can cause instability on repeated or multi-page scans
• Removing legacy backends can significantly improve reliability

Conclusion

This issue was not caused by Ubuntu, the scanner hardware, or the network connection. The root cause was the interaction between a modern HP network scanner and a legacy scanning backend (HPLIP) that is no longer well suited for this type of device.

Switching fully to AirScan resolved the instability completely and restored reliable scanning behavior.

Anyways, enjoy the first article, more to follow soon :) (or in a couple of months, we'll see ;) )

The C64 users always had an inconvenient little problem with the machine – lack of convenient reset button. They devised a lot of different minor and major modifications to solve that problem. There’s a lot to say about all of them, but one has speciffically caught my attention and I decided to apply it in my own modded C64C.

I’m talking about a small project, that I’ve found while browsing through C64 websites. It’s author cleverly used  a cheap and highly available Atmega microcontroler circuit – Arduino Pro Mini.

Original article can be located here: http://www.breadbox64.com/blog/switchless-reset-mod/, but I’ll describe a version that I’ve updated with a few minor tweaks.

The concept is simple, we upload a program into the circuit, which based on input signals (in this case the RESTORE button press) controls the signals sent to Commodore`s motherboard resulting in warm or cold reset and state changing on an address line of optionally installed EEPROM memory.

Beware! Before you grab a soldering iron and happily decide to install the modification in your favourite C64 remember, that any hardware alteration can lead to unintended damage.

What will be required for this project?

A USB capable PC, which will run the official Arduino toolkit (https://www.arduino.cc/). Of course the Arduino Pro Mini circuit is the key element of this project. When purchasing, take care to select the correct version. There are two variants, one runs on 5V and the other on 3.3V. Since the Commodore 64 also uses 5V, it’s necessary to choose that version.

To be able to program the circuit we’ll also need an USB to RS232 adapter (don’t confuse one with UART programmer, which looks almost identically). I recommend FDTI232 programmers, which work without a hitch on the latest OS’es and are also equipped with DTR output,  allowing automatically reset the Arduino before programming begins. Unfortunately most of available tutorials fail to mention that and asks the user to manually press reset button in a very speciffic moment, which is very tedious and can cause a rageous reaction, when you’re attempting to sync it correctly for the twentieth time.

Aside those two devices we’ll also need 5 or 6 wires to connect all the necessary signals, depending on if we also want to use the rom selector.

Programming the Arduino

After installing the toolkit and adapter driver, start up the Arduino IDE and paste in the code listing attached with this article.

Now let’s connect the Arduino Pro Mini in a following fashion:

- ground on the adapter to ground of Arduino,

- Vcc on the adapter to Vcc on Arduino,

- Rx on the adapter to Tx on Arduino,

- Tx on the adapter to Rx on Arduino,

- DTR on the adapter to DTR or Reset on Arduino.

Next select propper circuit board from the menu Tools > Circuit board… > Arduino Pro or Pro Mini. The processor we’re using Tools > Processor… > Atmega 328p (5V, 16MHz) and the adapter Tools > Programmer > AVRISP mk II.

If everything was configured and connected correctly, after pressing Upload button, the Arduino should blink it’s diodes a few times and the IDE will notify us that the upload was successful. If any error occurs, make sure all the steps up to now were done correctly.

Installation

Now it’s time to proceed with the hardware part of the solution. We have to connect the board accoarding to the following scheme:

• Vcc on Arduino to +5V line on the C64 motherboard,
• GND on Arduino to GND on the C64 motherboard,
• A0 analog I/O line to RESTORE button line on the C64 motherboard,
• digital I/O line 3 to CPU Reset line on the C64 motherboard,
• digital I/O line 4 to /EXROM line on the C64 motherboard,
• digital I/O line 5 to leg 27 of the EEPROM memory (optionally).

Sounds complicated? Unfortunatelly that’s the hardest part of the whole mod and because a lot of different versions of the C64 motherboard exsist, it’s very probable that you’ll need some aid from the service manual to find where exactly are all the signals on the one you have.

Anyway, for now we’ll use a popular C64C motherboard variant as an example – Assy No. 250469 Rev. B.

First we need to supply 5V to the circuitboard, which we’ll find in a lot of places all over the C64 board. I went with a comfortable location right beside the POWER LED pins. Looking at the motherboard from the usual spot we take when we use the Commodore, +5V can be located on the first free soldering point on the left of the LED pins.  In the same line just beside there’s also a point with ground. It’s worth to make sure and confirm the correct values with a Voltometer.

The RESTORE signal is also relatively easy to find on this motherboard. We’ll locate it almost at the bottom edge of the board, on one of the R17 resistor legs (the one near the neighbouring capacitor). Why use the RESTORE button? Because it’s the only one that’s has a direct connection on the motherboard and isn’t in any way coded.

The RESET line can be located on the anode of CR5 diode, which you’ll find just above the character ROM. Unfortunately it’s difficult to solder a wire in from the upper side of the board, which gives us two options, either to move the diode, or to solder the wire from the backside, which I did.

The most difficult to locate for me was the /EXROM line. On my motherboard the soldering point was covered up by a sticker. Also near the bottom edge between PLA and the VIC-II chips you’ll find five soldering points in a row. Counting from the left, the fourth one is the /EXROM line.

If your C64 is also equipped with a dual ROM, it’s possible to connect one of it’s legs to the I/O line 5. The attached code allows to switch between two ROM locations, but it’s possible to add in support for four. Keep also in mind that in the old C64 models Basic and Kernal were located in separate ROM chips, unlike the C64C where they only use one.

If everything was connected correctly, you can test the solution.

How does it work?

The mod adds a few functions to our C64, depending on how long we’ll press the RESTORE button. Pressing it for two to four seconds, executes a so called warm reset, which starts the Basic setup routine and redraws the screen. If that’s not sufficient, because let’s say part of the memory was overwritten by users code, it’s possible to do a longer, four to seven seconds press and execute a cold reset instead. This takes the Commodore through the complete startup routine and works in a same fashion as a reset button on a cartridge. If the computer has the dual ROM installed and connected, it’s also possible to press RESTORE for seven to ten seconds and this in turn will do a cold reset and additionally switch the currently used ROM location.

For cartridge compatibility purposes I’ve also added the ability to start up the machine using the second ROM, by pressing the RESTORE button during the power on.

And voila! This way we’ve supplied our good old C64 with a neat CTRL+ALT+DELETE equivalent without drilling any holes or damaging the housing. To make the solution more elegant and easier to dismount it’s possible to use goldpin connector instead of directly soldering in the wires.