Add Drupal OAuth2 support into core lib
When validating requests through OAuth, the 2 important specs to consider for support are https://www.rfc-editor.org/rfc/rfc6749 and https://datatracker.ietf.org/doc/rfc7662/, which represent the base OAuth2 authorization endpoints and the introspection endpoint respectively. These 2 standards represent the ways in which servers can both authenticate and validate tokens. In our Drupal sites currently, we make use of a module that is only compliant with the first and breaks the second explicitly. This means that we cannot easily support authentication through the Quarkus-provided mechanisms.
In solving this, there are 2 options for resolving this, one being integrated and complex, the other being simple and non-integrated. For purposes of not introducing complexity that may conflict with other plugins, as well as reducing technical complexity for a feature that may not be supported long-term as we plan to move more into Keycloak in the future, I suggest we implement the simpler approach. @cguindon let me know if you have any questions or concerns about this.
To support a few upcoming features where we need to validate an OAuth token from Drupal, we should add an API binding and supporting features to the core library. The URL we need to use to check this is https://accounts.eclipse.org/oauth2/tokens/<the bearer token to validate/check>
. The body return from Drupal has the following response model:
{
"client_id": "string, client ID that owns/generated token",
"user_id": "string, the user ID that owns this token, nullable",
"access_token": "string, actual access token, which should match what we put in URL",
"expires": long, millis from epoch of when token expires,
"scope": "String, space-separated values for available scopes"
}
We'll want to add a helper for this as well to simplify a few operations. This will include DrupalAuthHelper#isExpired
and DrupalAuthHelper#hasScope
, which will allow us to centralize and test this logic easily. I could go either way on a service for this, as we could centralize some of the logic, but we need to be careful that there is no caching as we need to revalidate tokens on every request.