question: Environment variables in Google OAuth example

[bogosj]

I want to set up Google OAuth in front of various services in my existing Caddy set up. Looking through the example file:
https://github.com/authp/authp.github.io/blob/main/assets/conf/oauth/google/Caddyfile

What is JWT_SHARED_KEY?

Is the (tls_config) necessary? That appears to be using manual certs instead of Let's Encrypt?

https://assetq.myfiosgateway.com - I assume this should be like https://myservice.mydomain.com.

Presumably this could run on port 80 and 443 instead of the non-standard ports?

[greenpau]

I want to set up Google OAuth in front of various services in my existing Caddy set up.

@bogosj , thank you for the issue!

What is JWT_SHARED_KEY?

That is a shared key. The {env.JWT_SHARED_KEY} is the {env.<ENV_VAR} placeholder described here.

Is the (tls_config) necessary? That appears to be using manual certs instead of Let's Encrypt?

It is not necessary if you are using Let's encrypt.

https://assetq.myfiosgateway.com - I assume this should be like https://..com.

Yes.

Presumably this could run on port 80 and 443 instead of the non-standard ports?

Correct. You just need to keep in mind the binding to privileged ports

[bogosj]

Thanks. For the shared key is the suggested method creating a random GUID/UUID?

[greenpau]

For the shared key is the suggested method creating a random GUID/UUID?

@bogosj, random yes. GUID/UUID - no 😄 (because in theory it could be guessed), but it easier to explain it. I would say generate anything between 64-96 characters long.

If you are running everything on a single instance and you don't care about re-authentication about reboot, then don't specify any crypto directives and ECDSA keys would be automatically generated for you.

Separately, you could also setup https://authp.github.io/docs/authorize/token-verification#verification-with-rsa-and-ecdsa-keys

[bogosj]

I guessed at a GUID because at the top of the page you reference there's a shared key:

crypto key verify 383aca9a-1c39-4d7a-b4d8-67ba4718dd3f

[greenpau]

I guessed at a GUID because at the top of the page you reference there's a shared key:

@bogosj , that's correct 😄 I can't make up good passwords, so I resort to uuidgen 😃

[bogosj]

I removed the crypto blocks as suggested. I kept getting an error that looked like:

authorize is not ordered, so it cannot be used here

Apologies, the docker container logs disappeared after re-building so I don't have an exact copy of it.

I added:

	order authenticate first
	order authorize after authenticate

To the top of the global block and that seems to have fixed it.

[greenpau]

To the top of the global block and that seems to have fixed it.

@bogosj , 👍 I will update docs with these.

[greenpau]

@bogosj , after re-reading https://caddyserver.com/docs/caddyfile/directives

i am convinces that the order should be

order authenticate before respond
order authorize before basicauth

[bogosj]

Perhaps I'm misunderstanding but now that I read those docs shouldn't it be:

order authenticate before basicauth
order authorize before respond

[greenpau]

order authenticate before basicauth

@bogosj , good question 👍 To answer it, one has to have some experience writing plugins for caddy, because I've never seen a doc explaining it.

Authenticate

The authenticate plugin is of http.handlers type.

caddy-security/plugin_authn.go

Line 47 in 8f1d6f6

ID: "http.handlers.authenticator",

This type of plugins perform ServeHTTP function.

caddy-security/plugin_authn.go

Lines 96 to 101 in 8f1d6f6

	// ServeHTTP serves authentication portal.
	func (m *AuthnMiddleware) ServeHTTP(w http.ResponseWriter, r *http.Request, _ caddyhttp.Handler) error {
	rr := requests.NewRequest()
	rr.ID = util.GetRequestID(r)
	return m.Authenticator.ServeHTTP(r.Context(), w, r, rr)
	}

It is from the same category as the ones below (ref)

# handlers that typically respond to requests
abort
error
respond
metrics
reverse_proxy
php_fastcgi
file_server
acme_server

The abort and error directive we could skip. That leaves us with respond being another plugin that performs ServerHTTP.

Authorize

The authorize plugin is of http.authentication.providers type.

caddy-security/plugin_authz.go

Line 50 in 8f1d6f6

ID: "http.authentication.providers.authorizer",

This type of plugins perform Authenticate function (the naming is a bit inconsistent with the intent ... but it works in the context of basicauth plugin).

caddy-security/plugin_authz.go

Line 101 in 8f1d6f6

func (m AuthzMiddleware) Authenticate(w http.ResponseWriter, r *http.Request) (caddyauth.User, bool, error) {

This type of plugin is NOT supposed to write HTTP response body, because subsequent plugins would not be able to write response headers and body.

Also, note the caddyauth.User in the response.

It is from the same category as the ones below (ref)

# middleware handlers; some wrap responses
basicauth
request_header
encode
push
templates

Being prior to basicauth would be the correct choice.

[greenpau]

@bogosj , updates the configuration files in the docs with the order directives. Thank you for the issue! 👍 Please consider https://github.com/greenpau/caddy-security/issues/14#issue-1111599735