• Members 12 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 12 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 12 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 12 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 12 posts
    Jan. 23, 2023, 3:49 p.m.

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