• Members 125 posts
    Jan. 23, 2023, 12:43 a.m.

    Authelia is about to release a major update, that adds OAuth 2.0 Pushed Authorization Requests. Would this allow it to be used as an authorisation provider to misago?

  • Jan. 23, 2023, 2:20 a.m.

    From my understanding „Pushed Authorization Requests” means that flow is initialized by the client making a HTTP request to the server before redirecting user to it for them to fill in the login form. This is what Twitter does for their OAuth 2 service and its not supported.

    I am not familiar with Authelia. Is it required by their OAuth 2 implementation that clients do PAR to start the auth flow?

    If they also support the classic flow where user is redirected to the login form with the state, scope, client id and redirect in the URL, it should work.

  • Members 125 posts
    Jan. 23, 2023, 9:15 a.m.

    I have a less than full understanding of auth in general. This is an expansion of functionally from authelia. Strictly they do not provide oauth 2 support. Except as a subset of an incomplete OIDC implimentation (which is nevertheless both useful, and widely used). It struck me that it definitely wouldnt work before, but that the latest version might make it possible.

    Authelia is the lightest, simplest, most complete auth for self hosting. I want to see if I can have misago work with it. If I can't I will pursue different forum options. It is contrary to the ethos of the services that I provide to my users to delegate auth to a third party, and I do not want to commit my stack to a heavyweight complex solution (like Keycloak or authentik) for the sake of one service. I do need SSO and central source of truth (I use lldap behind authelia and that allows users self set and reset with password and 2fa).

  • Jan. 23, 2023, 11:28 a.m.

    Let me know if I understand this right:

    1. Authelia is a middleware for HTTP server
    2. You configure in HTTP server that my-misago.com should require an auth
    3. You access the my-misago.com
    4. You don't have the authelia-cookie so HTTP server displays you the Authelia login page
    5. You complete the login in Authelia and it now sets the authelia-cookie on my-misago.com domain
    6. You are redirected to my-misago.com
    7. You have a authelia-cookie, so HTTP server displays you Misago site instead of Authelia login page
    8. authelia-cookie is a JWT, which Misago should decode and use to create/update user account on Misago forum and then authenticate the user for


  • Members 125 posts
    Jan. 23, 2023, 1:58 p.m.

    I haven't entirely got my head around it, but I think you are correct. If I can just backtrack, I use authelia in two ways. Firstly in conjunction with the reverse proxy it allows (or doesn't) access to a particular service. So a forward from the reverse proxy can be set to go via authelia (with the option to bypass, one-factor, or two-factor). This is, of course, irrelevant to this issue.

    Having logged in to the authentication portal, the service is presented, and one can use authelia as the authentication and authorisation server for the service. ie. Sign in, based on authelia hosted credentials.

    So if misago is the service, can it utilise the endpoints that authelia provides? I've had a look, and I think it can*. What I don't know is how misago can handle that. How to map authelia provided scope to misago (username, displayname, email, avatar, etc) authenticated users. How to automatically create a user that does not already exist in misago.

    I realise that you are asking me these sort of questions, I am trying to frame it in a structure that I understand, and is driven by what I actually want to get to. Of course this is all completely irrelevant if authelia can't provide an endpoint that conforms to misago's expectations.

    The best current example that I can find, which seems to be OAuth 2 rather than explicitly OIDC, is Hedgedoc. I have set this up exactly as the Hedgedoc/authelia integration guide. This appears to work as expected. When the hedgedoc service is connected to, it displays an un-authenticated instance. Choosing "Sign In" offers the option "Sign in via Authelia"

    Accepting that logs the authelia authenticated user in to hedgedoc.

    That would be functionality that I would like.

    [extended discussion almost certainly out of scope]

    Before the internet became the wild west, my forum members used to log in with "comedy" guest names, to make amusing posts in the 'style' of a well known character. "E.L. Wisty", "img" etc for making anonymous posts attributed to a particular style. We have had to curtail that, and enforce logging in to eliminate spam. It seems to me that it might be possible to allow certain misago endpoints through the reverse proxy auth, such that read only access could be enabled using authelia access control. Then it might be possible to log in to misago using 'reserved' usernames (with no password, or a published password, but not insecure because log in to the reverse proxy would be necessary to have access to the login portal in misago), that are not part of the authelia auth system....and then also be able to log in as a user authorised and authenticated through authelia.

    So the cherry on the top would be that:
    a. I could bypass the authelia/reverse proxy integration just for read only access to misago
    b. I could log in to the authelia portal and then:
    i. Log in as a misago user
    ii. Log in as an authelia user, who is mapped (or created as) a misago user who can only log in via authelia

  • Jan. 23, 2023, 3:40 p.m.

    I'm fraid somebody would have to install Authelia locally, setup Misago as an OIDC service for it and see if Authelia exposes those OAuth 2 urls:

    • URL for Misago to redirect to for Authelia to ask user to confirm the login.
    • URL for Misago to exchange the grant for access token.
    • URL for Misago to exchange the access token for user data.

    Looking at their reference. I see they have authorization_code as grant (which should work as access token for OAuth 2). I also see their scopes cover the needs (openid email profile provides all that Misago needs).

    So OAUTH 2 client would have to be setup with ID and secret from Authelia config, openid email profile scope, https://yourforum.com/oauth2/complete/ redirect URL to Misago and access_token grant. But how to configure login/access token/user retrieval steps I can't find. Is the token URL https://auth.example.com/api/oidc/token? Is the user data endpoint https://auth.example.com/api/oidc/userinfo?

    If Authelia has those URLs, it should work. I could investigate those myself but I don't know when I would have time to do this. But this flow is also different flow from one I've described above

  • Members 125 posts
    Jan. 23, 2023, 3:44 p.m.

    I'm trying to have a look at it.

    Firstly I'm trying to build and deploy misago under podman.

  • Members 125 posts
    Jan. 23, 2023, 3:49 p.m.

    I believe that to be correct. Those are the discoverable endpoints, according to the authelia documentation.

  • Members 125 posts
    Feb. 2, 2023, 12:18 p.m.

    I'm currently not making much headway with this.

    I need to know a lot more about oauth, and what misago needs, to be able to do so. I'm looking into it alongside other things.

  • Members 125 posts
    Feb. 2, 2023, 2:57 p.m.

    This is the work done on authelia, in regard to open ID connect (and the underlying oauth2).

    Is there anything here that suggests that there is a possible route for authentication for misago (or something that suggests it's not possible)?

    Beta 1

    complete v4.29.0

    Feature List:

    Beta 2

    complete v4.30.0

    Feature List:

    Beta 3

    complete v4.34.0

    Feature List:

    Beta 4

    complete v4.35.0

    Feature List:

    Beta 5

    complete v4.37.0

    Feature List:

    • JWK’s backed by X509 Certificate Chains
    • Hashed Client Secrets
    • Per-Client Consent Mode:
      • Explicit:
        • The default
        • Always asks for end-user consent
      • Implicit:
        • Not expressly standards compliant
        • Never asks for end-user consent
        • Not compatible with the consent prompt type
      • Pre-Configured:
        • Allows users to save consent sessions for a duration configured by the administrator
        • Operates nearly identically to the explicit consent mode

    Beta 6

    in progress v4.38.0

    Beta 7

    not started

    Feature List:

    • Prompt Handling
    • Display Handling

    See OpenID Connect Core (Mandatory to Implement Features for All OpenID Providers).

    Beta 8

    not started

    Feature List:

    General Availability

    not started

    Feature List:

    • Enable by Default
    • Only after all previous stages are checked for bugs


    This stage lists features which individually do not fit into a specific stage and may or may not be implemented.

    OpenID Connect Dynamic Client Registration

    not started

    See the OpenID Connect website for the OpenID Connect Dynamic Client Registration specification.

    OpenID Connect Back-Channel Logout

    not started

    See the OpenID Connect website for the OpenID Connect Back-Channel Logout specification.

    Should be implemented alongside Dynamic Client Registration.

    OpenID Connect Front-Channel Logout

    not started

    See the OpenID Connect website for the OpenID Connect Front-Channel Logout specification.

    Should be implemented alongside Dynamic Client Registration.

    complete v4.34.0

    See the IETF Specification RFC8414 for more information.

    OpenID Connect Session Management

    not started

    See the OpenID Connect website for the OpenID Connect Session Management specification.

    End-User Scope Grants

    not started

    Allow users to choose which scopes they grant.

    Client RBAC

    not started

    Allow clients to be configured with a list of users and groups who have access to them.

    Preferred Username Claim

    complete v4.33.2

    The preferred_username claim was missing and was fixed.

  • Feb. 2, 2023, 10:03 p.m.

    TL;DR is this:

    OAuth 2 is standard for one application to make user provide their access token to it from other application. This access token can then be used by an app to represent as user to other apps. This is where OAuth 2 standard ends. There's nothing about user retrieval in it.

    OpenID Connect extends OAuth 2 standard with standard for retrieving user data. So now you not only get user's access token, there's also standard way to get user's info.

    Misago implements OAuth 2 standard, so it can be configured to retrieve user's access token from other service. BUT this token is useless on its own for Misago, so it also implements user info retrieval mechanic that OpenID describes.

    Basically, those things:

    "Authorization Code Flow" and "User Consent" are OAuth 2. "Userinfo Endpoint" is the API that Misago connects to once it has access token from OAuth 2 to get user data to create/update in it's database.

  • Feb. 2, 2023, 11:04 p.m.

    Doesn't Authelia have a forum or a community where you can just ask how to retrieve configuration data for Misago's OAuth 2 client?

  • Feb. 6, 2023, 12:13 p.m.
  • Members 125 posts
    Feb. 6, 2023, 6:14 p.m.

    Yes, and I have it working in an app using oauth2 ( hedgedoc ). I just can't work out the misago end settings to make it function.

  • Feb. 6, 2023, 9:11 p.m.

    What have you tried?

  • Members 125 posts
    Feb. 6, 2023, 9:18 p.m.

    I've got it redirecting to authelia as the auth provider. I have authelia confirming the request for auth and to share the scopes. I have it redirecting back to misago.

    Misago isn't getting an access token, or the userinfo.

    So I am not understanding what request misago has to make, and where/how the access token is to be found. So that's part how authelia serves it, part how to structure the settings in misago to access it.

  • Feb. 6, 2023, 9:25 p.m.

    Lets start with access token. The url according to hedgedoc is https://<your-authelia-url>/api/oidc/token. Does it require get or post? How should the grant be sent to it? How JSON response from Authelia looks like?