Reopen one of the "Resource Server/Opaque token introspection" issues/PRs

[nbrugger-tgm]

Issue description

Over the years there have been multiple issues/PRs requesting/contributing a resource server implementation using opaque tokens.

Issue/PR	Closing reason	Comment
#3	Please ask this question in Gitter or create a discussion	gitter doesn't exist anymore and no further replies in ticket
#91		no reason given, was redopened and closed
#94		no reason given for rejection of PR. Afterwards a comment "Seems to be already integrated https://micronaut-projects.github.io/micronaut-security/latest/guide/#clientcredentials ?" which is false since the mentioned guide has nothing to do with Opaque Token intospection. No further replies in PR
#1786	not closed	The ticket wasn't closed but set to "status: awaiting feedback without any actionable task (such as a question)

I do not just want to duplicate what was discussed there and i think it is more productive to continue one of the given tickets than have a fifth thread with the same discussions, it doesn't help anyone to have the same thread every ~1-2 years. But since in every thread a re-occurring pattern was that the requirement/what was asked for, was not well understood (there are many different flows that got intermixed or miss-named) i will try to the best of my ability to clarify.

Here is a diagram depicting the desired flow

sequenceDiagram
    participant RS as Micronaut APP
    participant UA as Browser
    participant AU as OAuth Server
    UA ->> AU: Some OAuth/OIC flow
    AU ->> UA: Opaque bearer token (example: GJ73F5CD) **NOT JWT**
    destroy UA
    UA ->> RS: GET /protected [BEARER: GJ73F5CD]
    RS ->> AU: /introspect [Payload: GJ73F5CD]
    AU ->> RS: 200 [Payload:<Some JWT with claims>]
    note over RS: Processes the JWT (validating, fetching roles, caching ...) <br/> same as if the original request contained it

Loading

In this case Browser is just a generic user agent (mobile device, server side application with session ...).

This exact flow was implemented by the aformentioned #94 (which has a missleading PR name) but implements #3 #91 and #1786.

The idea is that some user agent, be it a web app, a mobile device or a service using a client credential flow can authenticate against an oauth server, obtain a non jwt token and use this opaque token to request resources/endpoints agains a service that uses micronaut(-security) and micronaut security uses the config described here https://micronaut-projects.github.io/micronaut-security/latest/guide/#introspection in accordance to https://tools.ietf.org/html/rfc7662 to see if the token of the requester is valid (and get roles and so on)