Can't locate API module structure 'mod_oauth2' about mod_oauth2

[wnm3]

I used the command to list the exposed functions: nm -D /etc/httpd/modules/mod_oauth2.so
and saw oauth2_module so I tried that. Now it is loading but it doesn't appear to like the position of the AuthType in the httpd.conf file. Where should these be placed? I put them here:

<VirtualHost *:443>
  ServerName myserver.com
  ErrorLog   "/var/log/httpd/com.humidor-error_log"
  CustomLog  "/var/log/httpd/com.humidor-access_log" common

#wnm3 added for OAUTH
AuthType oauth2
OAuth2TokenVerify introspect http://localhost:9091/secure introspect.auth=none
OAuth2AccessTokenIn post name=access_token

[wnm3]

I moved statements out of httpd.conf and into oauth2.conf in the same directory. Complaints stopped but not getting any request sent to the introspect server.

[zandbelt]

the server debug logs should tell you what happened

[wnm3]

The dearth of documentation makes it difficult to guess how to use this module. Nothing shows as debug relating to oauth2_module other than it is loaded. I'm sure the problem is between the chair and keyboard, but an example config to call an OAUTH2 Validation Server might help. I've provided my settings above, but nothing is triggering the call to the server I configured. I'm making a POST call with a body containing the token (one valid and another time with invalid) but neither is forwarded to the introspect server above.

Do you see anything wrong in my configuration above (e.g., do I need to use SSL to call the introspect server, am I missing an = sign somewhere)?

Can you please confirm no changes are needed in the ssl.conf or httpd.conf other than loading the module and that the configuration for oauth2 can go in the oauth2.conf file?

[zandbelt]

the sample introspection config is here:
https://github.com/zmartzone/mod_oauth2#quickstart
You'll need to protect the path you're accessing with AuthType oauth2.
You can put all of the config in the http.conf, or load the oauth2.conf in there.

[wnm3]

So, httpd.conf:
LoadModule oauth2_module /usr/lib64/httpd/modules/mod_oauth2.so
Include conf/oauth2.conf

and oauth2.conf:
#wnm3 added for OAUTH
AuthType oauth2
OAuth2TokenVerify introspect https://localhost:9091/secure introspect.auth=none
OAuth2AcceptTokenIn post name=token

And error reported:
AH00526: Syntax error on line 2 of /etc/httpd/conf/oauth2.conf:
AuthType not allowed here

The oauth2.conf example shows AuthType commented out, yet the Examples referenced in your quickstart link above show it active.

I commented out the AuthType line and it starts.

[wnm3]

I am still unable to get any request forwarded by oauth2 to my Authentication Server (e.g., I'm using a curl with a POST to the apache server with the token=sssss in the payload) and nothing is received by the Authentication server.

[wnm3]

Thank you for your patience...

Okay, I've reversed the order of the so the basic auth is above the oath2 and now things are almost working. The server I'm testing with has old expired certificates and unfortunately, the ssl_verify=false doesn't allow for that circumstance. I can see that the proper token has been found in the request.

[Fri Aug 13 01:56:38.854130 2021] [oauth2:error] [pid 236240] [client 10.33.40.110:43294] oauth2_http_call: curl_easy_perform() failed on: https://myserver.com:9091/secure (Peer certificate cannot be authenticated with given CA certificates: Peer's Certificate has expired.)
[Fri Aug 13 01:56:38.854202 2021] [oauth2:debug] [pid 236240] src/http.c(1085): [client 10.33.40.110:43294] oauth2_http_call: leave [0]: (null)
[Fri Aug 13 01:56:38.854210 2021] [oauth2:debug] [pid 236240] src/oauth2.c(443): [client 129.34.40.110:43294] _oauth2_introspect_verify: leave: 0
[Fri Aug 13 01:56:38.854214 2021] [oauth2:debug] [pid 236240] src/oauth2.c(725): [client 129.34.40.110:43294] oauth2_token_verify: leave: 0
[Fri Aug 13 01:56:38.854218 2021] [oauth2:debug] [pid 236240] src/server/apache.c(321): [client 129.34.40.110:43294] oauth2_apache_return_www_authenticate: enter
[Fri Aug 13 01:56:38.854227 2021] [oauth2:debug] [pid 236240] src/server/apache.c(413): [client 129.34.40.110:43294] oauth2_apache_hdr_out_add: WWW-Authenticate: Bearer realm="Restricted Content", error="invalid_token", error_description="Token could not be verified."

I'll try to setup new certificates and hope all will work as advertised.

One question I have is the RFC 2276 seems to require an obsolete form of Content-Type. I'd prefer to use application/json if possible so I can add the token to the rest of the payload I want forwarded to the downstream services. Will your system find the token if passed in application/json rather than application/x-www-form-urlencoded?

[zandbelt]

As mentioned in the sample that I linked to, you can set introspect.ssl_verify=false to disable certificate validation.

I'm not sure how RFC 2276 relates to this.

[wnm3]

I'd found another line where there was a typo for ssl_verify so it was remaining true. I fixed that and get past the verification as you'll see below. I get tripped up now on user validation. My request has a basic authentication header and has the token for OAUTH2 in the payload. I'm not sure how to disable or fix the remote user claim not found issue (e.g., it doesn't appear related to the Apache user authentication from the Authorization Basic header), so I'm misunderstanding something basic.

I had the wrong RFC number (dyslexic...) -- 7662 token introspection is what I'd meant. My question was, would your module be able to find the token if the payload of the POST request was sent in application/json form so I could also send the rest of my payload I want to forward to downstream services after passing authentication. The spec only talks about application/x-www-form-urlencoded but perhaps this is solely for the call oauth2_module is making to my authentication server and your module is fine with receiving application/json and is smart enough to find the token there to form the request. Unfortunately, oauth2_module is only expecting x-www-form-urlencoded so sending JSON in the payload fails.

My overall goal was to configure a client app (no user experience, just a service) with knowledge of a valid access token (derived by a person and configured in this client service) and have it send its POST request to the Apache HTTPD gateway. I wanted the token to be used to validate the request was allowed before using the proxy to forward the request to downstream services. These services expect application/json payloads. However it appears the oauth2 requires x-www-form-urlencoded content. So, not sure how this is done normally.

oauth2_http_call: enter: url=https://myserver.com:9091/secure, data=token=971205560664324457525695621726&token_type_hint=access_token, ctx=[ ssl_verify=false hdr=[ Content-Type=application/x-www-form-urlencoded ] cookie=[ ] ]
http://localhost:9091/secure shared
AH00927: initializing worker http://localhost:9091/secure local
AH00931: initialized single connection worker in child 19230 for (localhost)
AH00925: initializing worker https://localhost:9091/code shared
AH00927: initializing worker https://localhost:9091/code local
AH00931: initialized single connection worker in child 19230 for (localhost)
AH00925: initializing worker https://localhost:9081 shared
AH00927: initializing worker https://localhost:9081 local
AH00931: initialized single connection worker in child 19230 for (localhost)
oauth2_http_call: HTTP response code=200
oauth2_http_call: leave [1]: {"_id":"6111803026dcf63aa32c3806","access_token":"971205560664324457525695621726","active":true,"exp":1631128880591,"iat":1628536880591,"iss":"OAUTH Authorization Server"}
_oauth2_introspect_verify: leave: 1
oauth2_cache_set: enter: key=971205560664324457525695621726, len=179, ttl(s)=300, type=shm, encrypt=0
_oauth2_cache_hash_key: enter: key=971205560664324457525695621726, algo=(null)
oauth2_jose_hash_bytes: enter
oauth2_jose_hash_bytes: leave: 1
_oauth2_cache_hash_key: leave: hashed key: 4f73e2a855f03cbc1de4067f20b5c8ca0a6763c9399503dcaecd863ca6b9f7e3
oauth2_cache_shm_set: enter
oauth2_cache_shm_set: leave: 1
oauth2_cache_set: leave: successfully stored: 971205560664324457525695621726
oauth2_token_verify: leave: 1
oauth2_apache_set_request_user: remote user claim could not be found
oauth2_apache_return_www_authenticate: enter
oauth2_apache_hdr_out_add: WWW-Authenticate: Bearer realm="Restricted Content", error="invalid_token", error_description="Could not determine remote user."
oauth2_apache_return_www_authenticate: leave
oauth2_request_handler: leave
AH01503: headers: ap_headers_error_filter()
oauth2_apache_request_context_free: dispose request context: 0x56480e1d13c0
AH02001: Connection closed to child 0 with standard shutdown (server myserver.com:443)

[zandbelt]

you'll need to set a claim that exists in your introspection result, so in your case probably:

OAuth2TargetPass remote_user_claim=_id

see https://github.com/zmartzone/mod_oauth2/blob/v3.2.2/oauth2.conf#L138-L150

there's no standardized way to send an access token in a JSON body, so the module only supports what is in the spec

[wnm3]

Sorry about this never ending issue -- I will be happy to try to summarize everything so others could benefit once I've resolved my issues...

I've set up ssl.conf as follows with just 2 location sections (httpd.conf has none):

LogLevel oauth2:debug

<Location />
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/httpd/.htpasswd
Require valid-user
</Location>

<Location />
AuthType oauth2
OAuth2AcceptTokenIn post name=token
OAuth2TokenVerify introspect https://myserver.com:9091/secure introspect.ssl_verify=false&introspect.auth=basic&username=myuserid&password=mypassword
OAuth2TargetPass authn_header=_id
</Location>

And I am sending back an _id field that has the Authorization header (e.g., "Basic xxxxxxx") and was hoping the authn_header would set this in the Authorization field to be authorized to forward the request to be proxied to the actual location where the service is provided.

However, instead, I still get errors in ssl_error_log (some data obfuscated):

oauth2_http_call: HTTP response code=200
oauth2_http_call: leave [1]: {"_id":"Basic d32tMzpWetcNGVmYw==","access_token":"98712055695621726","active":true,"exp":1631128880591,"iat":1628536880591,"iss":"OAUTH Authorization Server"}
_oauth2_introspect_verify: leave: 1
... (caching statements)
oauth2_cache_set: leave: successfully stored: 98712055695621726

followed by the error being reported below. I'm sorry but I don't know what is failing so I'm not sure how to fix it.

oauth2_apache_set_request_user: remote user claim could not be found
oauth2_apache_return_www_authenticate: enter
oauth2_apache_hdr_out_add: WWW-Authenticate: Bearer realm="Restricted Content", error="invalid_token", error_description="Could not determine remote user."
oauth2_apache_return_www_authenticate: leave

oauth2 has received the Basic Authorization header in my original request, as well as in the _id field of the response from the Authorization Server, so has access to a userid and password. Do I need to add something more to the response from the Authorization Server to allow oauth2 to determine the remote user? My 200 response has the active=true so I'm not sure what token it thinks is invalid.

[zandbelt]

as mentioned it needs OAuth2TargetPass remote_user_claim=_id for that, (not authn_header...)

[wnm3]

Thank you -- sorry I misunderstood. It seems to be working. Will summarize and then you may close.

[wnm3]

Regarding standards for using application/json vs x-www-form-urlencoded (per rfc 7662) I found this draft:
https://tools.ietf.org/id/draft-richer-oauth-json-request-00.html

If we control the authorization service (so we don't care if the JSON request contains additional information) then this approach would allow us to take an existing JSON based API request, add oauth2_module for authorization passing the JSON request with the token to our Authorization Server, and having oauth2 allow or reject the request based on the response.

If allowed, the original request could be forwarded via proxy to the API server (albeit with the access token since I'm not aware of a way to remove something from the original request in oauth2_module).

Otherwise, without application/json support, it seems we'd have to recast our API to accept x-www-form-urlencoded content to process what oauth2_module allowed to pass.

[wnm3]

Summary:
My goal was to add OAUTH2 authentication for REST service requests flowing through an Apache HTTPD proxy server to downstream service providers. Apache is running on RHEL 7 so to configure the environment for mod_oauth2 to run I had to retrieve some dependency libraries:

From: https://www.gitmemory.com/issue/zmartzone/mod_oauth2/12/754667776

sudo yum install jansson-devel            (this avoids incorrect warning Requires: pkgconfig(jansson) >= 2.3)

wget https://github.com/zmartzone/mod_auth_openidc/releases/download/v2.3.0/cjose-0.5.1-1.el7.centos.x86_64.rpm rpm -iv ~/cjose-0.5.1-1.el7.centos.x86_64.rpm --nodeps

wget https://github.com/zmartzone/liboauth2/releases/download/v1.4.0.1/liboauth2-1.4.0.1-1.el7.x86_64.rpm sudo yum localinstall -y liboauth2-1.4.0.1-1.el7.x86_64.rpm

wget https://github.com/zmartzone/liboauth2/releases/download/v1.4.0.1/liboauth2-apache-1.4.0.1-1.el7.x86_64.rpm sudo yum localinstall -y liboauth2-apache-1.4.0.1-1.el7.x86_64.rpm

wget https://github.com/zmartzone/mod_oauth2/releases/download/v3.2.0/mod_oauth2-3.2.0-1.el7.x86_64.rpm sudo yum localinstall -y mod_oauth2-3.2.0-1.el7.x86_64.rpm

I configured the /etc/httpd/conf.d/ssl.conf configuration file to load the oauth2_module and added two locations (one for Basic authentication, and one for oauth2 authorization) -- Note the name of the module is oauth2_module and not mod_oauth2:

LoadModule oauth2_module modules/mod_oauth2.so

with the Location entries within the section (the LogLevel is optional but very helpful to see why things may fail in the logs/ssl_error_log) and the order of the location statements is important:

LogLevel oauth2:debug

<Location />
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/httpd/.htpasswd
Require valid-user
</Location>

<Location />
AuthType oauth2
OAuth2AcceptTokenIn post name=token
OAuth2TokenVerify introspect https://myserver.com:9091/secure introspect.ssl_verify=false&introspect.auth=basic&username=myuserid&password=mypassword
OAuth2TargetPass remote_user_claim=_id
</Location>

Notes:

1. My authorization server needs to support https requests (I turned off ssl verification in the OAuth2TokenVerify introspect command using introspect.ssl_verify=false
2. I provided a username and password so the request would container a Basic authoritzation header (it would be nice if we could have oauth2 forward the original header in the request to the authorization server somehow).
3. I had to specify where oauth2 could fine my token in the incoming requests using the OAuth2AcceptTokenIn post name=token statement saying it was in the POST body identified by "token"
4. Finally, I needed to provide OAuth2TargetPass remote_user_claim _id to tell oauth2 where to find the Basic Authorization I'd returned in the _id field of the authorization server's response so it could forward this to the Target.

This was all new to me and I really appreciate @zandbelt patience to labor through my trials and errors.