Altinn / Altinn/altinn-authentication
Verify whether the token introspection endpoint is still used (EFormidling)
- Dominant language
- C#
- Stars
- 8
- Forks
- 6
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 21
Description
## Summary
Verify whether the **token introspection endpoint** (`POST authentication/api/v1/introspection`) is actually used in production. If it isn't, it's a candidate for deprecation/removal (dead-code reduction); if it is, it should be documented and its one consumer confirmed.
## Background
- RFC 7662 token introspection endpoint: [`IntrospectionController`](https://github.com/Altinn/altinn-authentication/blob/main/src/Authentication/Controllers/IntrospectionController.cs) → [`AuthenticationCore.IntrospectionValidation`](https://github.com/Altinn/altinn-authentication/blob/main/src/Authentication/Services/AuthenticationCore.cs).
- `[Authorize]` (authenticated, machine-to-machine). Body is `IntrospectionRequest` (`token` + optional `token_type_hint`).
- The validator chain currently has **exactly one** validator — [`EFormidlingAccessValidator`](https://github.com/Altinn/altinn-authentication/blob/main/src/Authentication/Services/EFormidlingAccessValidator.cs). So its only purpose today is checking whether a token is a valid/active **EFormidling** access token. Returns `{ active, iss }`.
- `token_type_hint` is accepted but **not used** anywhere (only a comment about someday reordering the chain).
- History: introduced by Stephanie Buadu in **2021** (feature 7612 / PR #7639, originally in altinn-studio), migrated here in 2022, and essentially **untouched since** (only a recent nullable-annotation tweak). This "old + single-purpose + never-changed" profile is why it's worth confirming it's still live.
## Why this matters
If the endpoint has no live callers, it's dead surface area we maintain (and just had to touch for the nullable work). If it does have callers, we should know who and document it.
## Investigation / tasks
- [ ] Check Application Insights / access logs (prod + TT02) for requests to `POST /authentication/api/v1/introspection` over a representative window — is it called at all, and by whom (client/consumer)?
- [ ] Confirm whether the **EFormidling** integration still relies on this endpoint (ask the EFormidling/integration team).
- [ ] Confirm what token(s) `EFormidlingAccessValidator._validator.Validate` is configured to accept (issuer/audience) and whether that configuration is still valid in prod.
- [ ] Decide the outcome:
- **In use** → document the endpoint + its consumer (add to `docs/`), and remove the dead/unused `token_type_hint` handling comment or implement it.
- **Not in use** → deprecate and schedule removal of the controller, `IntrospectionRequest`/`IntrospectionResponse`, `EFormidlingAccessValidator`, and related wiring.
## Acceptance criteria
A documented decision on whether the introspection endpoint is used, with either (a) documentation of its live consumer, or (b) a removal plan if it's dead.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at src/Authentication/Controllers/IntrospectionController.cs and follow AuthenticationCore.IntrospectionValidation and EFormidlingAccessValidator.cs. Check production and TT02 Application Insights or access logs for POST /authentication/api/v1/introspection, and confirm EFormidling usage and validator configuration with the integration team. Done means docs/ contains a decision identifying the consumer or a removal plan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, authentication, security
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100