I've made an enquiry asking this.

I am mostly not understanding that as it flies over my head. But if there's a way, and you are prepared to do that, it is a valuable addition for me.

Hey one of the Authelia developers here. I'll separate this reply into multiple areas as this topic covers several sections of ratified standards. OAuth 2.0 has a lot of specs which extend it beyond just OpenID Connect 1.0. All linked specifications which include "OAuth 2.0" in my naming are specifically OAuth 2.0 / OAuth 2.1 standards which OpenID Connect 1.0 also benefits from, they can all be seen on the OAuth 2.0 website (oauth.net/2/).

Our integration guide: www.authelia.com/integration/openid-connect/introduction/

PKCE

OAuth 2.0 Proof Key for Code Exchange (RFC7636) is an OAuth 2.0 technology which enhances the Authorization Code flow to be more resistant to certain kinds of attacks. The code_verifier is not specifically required but can be configured to be required (by requiring PKCE) which is the default for public client type as per the OAuth 2.0 Best Practices (but can be disabled), or is required if the authorization request includes the code_challenge parameter (as per the spec).

This is very simple to implement and if you need help on implementation specifics, let me know. I'd recommend only implementing the S256 as the code_challenge_method as plain is not really useful.

PAR

OAuth 2.0 Pushed Authorization Requests (RFC9126) is standardized OAuth 2.0 technology that makes the OAuth 2.0 Authorization Request over the back-channel (client application to authorization server) using the POST scheme with all of the same request parameters as a standard OAuth 2.0 Authorization Request encoded as application/x-www-form-urlencoded to a separate URI, along with the relevant client authorization method (i.e. client secret).

The response includes an opaque URI which is used as a redirect_uri parameter in the standard request, without any of the other parameters I believe. This means the private information about the authorization request is never accessible by the end user or the end users potentially compromised device. Combined with PKCE it makes the Authorization Code flow basically the most secure flow in the OAuth 2.0 arsenal and effectively has almost zero attack surface.

It is specifically related to the OAuth 2.0 Authorization Code flow, and allows for any extensions like PKCE that exist to be used (if the specification is followed).

CSRF

While we don't require PKCE (except for public clients by default), we do not allow authorization requests which are likely vulnerable to CSRF per OAuth 2.0 Security Best Current Practice Section 2.1. For this reason we require a state parameter.

Discovery

Both OAuth 2.0 and OpenID Connect 1.0 support discovery documents which make this process much easier for users. Authelia supports both of these. Most information that users may need to configure can be configured via these methods. These documents include relevant endpoints, including PAR and PAR related configuration.These documents can be discovered purely by users providing the relevant issuer as the documents are at the following URI's for compliant providers:

• OAuth 2.0 Authorization Server Metadata (RFC8414): <issuer>//.well-known/oauth-authorization-server
• OpenID Connect Discovery 1.0: <issuer>//.well-known/openid-configuration

These standards would simplify the onboarding for users significantly.

User Retrieval

This is standardized in OpenID Connect 1.0 and is (mostly) the main differentiator which I think you know. One potential value add here is that the id_token can accompany the access_token from the token endpoint when the openid scope is requested. It may be beneficial to allow utilization of this in the future.

Authorization / Token Endpoint

I noticed a couple strange things in your implementation and with the understanding that it's early days I have a few comments.

The wording 'There is no standard for either login form URL or scopes. Consult the documentation of the solution you are using to find out valid values.' seems rather strange. The Authorization Endpoint does have a standardized input and is used for effectively this purpose. Maybe this is just a miscommunication thing?

It also appears like you allow GET requests to the token endpoint but this is expressly disallowed by OAuth 2.0 Section 3.2.

Yep this is correct. We require PKCE for the public client type by default, but the confidential client type it's off by default. Users get the ability to control this globally and have the ability (when 4.38.0 is released) to control it on a per-client basis allowing flexibility without compromising security. PAR is overkill even though it's incredibly cool.

I would still recommend PKCE being implemented (could be a simple checkbox in a future advanced section) even though it was intended for the public client type as it ensures a leaked client secret and a compromised authorization code (combined with properly configured redirect URIs) are not sufficient to retrieve any tokens.

Yeah this makes sense. Please don't take my comments as criticism in any way. I understand that struggle. I just saw you seem to be starting the integration with OAuth 2.0 and felt that I could quickly demystify some of these areas of the spec which seem cumbersome to understand.

Ahh, this explains it and makes sense. How rare for a big company like that to completely disregard the specifications. As an idea maybe this option should be hidden in an advanced section with an explanation where it defaults to POST? You know your users the best and how that may affect them and/or how well it fits your design.

Yeah I must just not have read it properly. So probably a miscommunication thing on my end with my eyes. ;)

Absolutely not demanding action, I'm very appreciative of the scope of work you have on, and you owe us nothing...but I am curious if there is an active intention (or broad timeline) to address the oauth stuff. It's only this that is currently stopping me putting misago into production for my use case (I can't move my community to a forum with independent auth - once I make that step I'm then stuck with it and it doesn't, and wont ever, integrate with my other user services).

Okay...I see what you are saying...but I haven't been able to come up with setting in misago, that provide auth through authelia.....I can get the endpoints, but the post settings, and the headers, and the access token name and other bit needed to provide a valid request, I don't seem to be able to do.,

In laymans terms are there any pointers to these...or are we all agreeing it's how it should be, but nobody knows how to make it work? :-)

Endpoints I understand, and can get working. When you say client id/secret what setting are you implying? When you say POST everywhere except on user retrieval, what setting should be used on user retrieval?

I have fiddled about with this quite a lot, and got nowhere other than the auth request/redirect, but without any return information/token.

I get the auth "Consent Request" to share profile, group, and email information. When it redirects back to misago that returns the error:

      - id: misago
        secret: <auth_secret>
        public: false
        authorization_policy: two_factor
        scopes:
          - openid
          - profile
          - groups
          - email
        redirect_uris:
          - https://myinstance.mydomain.com/oauth2/complete/
        grant_types:
          - refresh_token
          - authorization_code
        response_types:
          - code
        response_modes:
          - form_post
          - query
          - fragment
        userinfo_signing_algorithm: none

Is what I have. I'm starting to have a nagging thought that the way the application is proxied might contribute to the problem (caddy2>nginx>misago).

I don't understand this at all. I am fiddling around in the dark trying to find a magic formulae. With other apps (hedgedoc, gitea) I'm just providing the client id and secret, and it just works. So I totally accept there's an absense of understanding on my part.

What I have, which seems to work closest is setup. It makes the request, is redirected back to misago, but fails with the message "Could not sign in with Authelia, JSON sent by the OAuth2 provider did not contain a user id."

You are going to ask my why my setting are like that, and I have no idea. I'm completely in the dark.