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
67
-
-
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.
-
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).
-
Let me know if I understand this right:
- Authelia is a middleware for HTTP server
- You configure in HTTP server that
my-misago.comshould require an auth - You access the
my-misago.com - You don't have the
authelia-cookieso HTTP server displays you the Authelia login page - You complete the login in Authelia and it now sets the
authelia-cookieonmy-misago.comdomain - You are redirected to
my-misago.com - You have a
authelia-cookie, so HTTP server displays you Misago site instead of Authelia login page authelia-cookieis a JWT, which Misago should decode and use to create/update user account on Misago forum and then authenticate the user for
?
-
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 openid-connect implementation of authelia includes an OAuth 2.0 Endpoint.
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 -
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_codeas grant (which should work as access token for OAuth 2). I also see their scopes cover the needs (openid email profileprovides all that Misago needs).So OAUTH 2 client would have to be setup with ID and secret from Authelia config,
openid email profilescope,https://yourforum.com/oauth2/complete/redirect URL to Misago andaccess_tokengrant. But how to configure login/access token/user retrieval steps I can't find. Is the token URLhttps://auth.example.com/api/oidc/token? Is the user data endpointhttps://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
-
I'm trying to have a look at it.
Firstly I'm trying to build and deploy misago under podman.
-
I believe that to be correct. Those are the discoverable endpoints, according to the authelia documentation.
-
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.
-
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:
- User Consent
- Authorization Code Flow
- OpenID Connect Discovery
- RS256 Signature Strategy
- Per Client Scope/Grant Type/Response Type Restriction
- Per Client Authorization Policy (1FA/2FA)
- Per Client List of Valid Redirection URI’s
- Confidential Client Type
Beta 2
complete v4.30.0
Feature List:
- Userinfo Endpoint
- Parameter Entropy
- Token/Code Lifespan
- Client Debug Messages
- Client Audience
- Public Client Type
Beta 3
complete v4.34.0
Feature List:
- Proof Key Code Exchange (PKCE) for Authorization Code Flow
- Claims:
preferred_username- sending the username in this claim instead of thesubclaim.
Beta 4
complete v4.35.0
Feature List:
- Persistent Storage
- Tokens
- Auditable Information
- Subject to User Mapping
- Opaque RFC4122 UUID v4’s for subject identifiers
- Support for Pairwise and Plain subject identifier types as per OpenID Connect Core (Subject Identifier Types)
- Utilize the pairwise example method 3 as per OpenID Connect Core (Pairwise Identifier Algorithm)
- Claims:
sub- replace username with opaque random RFC4122 UUID v4amr- authentication method references as per RFC8176azp- authorized party as per OpenID Connect Core (ID Token)client_id- the Client ID as per RFC8693 Section 4.3
- Cross Origin Resource Sharing (CORS):
- Automatically allow all cross-origin requests to the discovery endpoints
- Automatically allow all cross-origin requests to the JSON Web Keys endpoint
- Optionally allow cross-origin requests to the other endpoints individually
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
- Explicit:
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:
- Revoke Tokens on User Logout or Expiration
- JSON Web Key Rotation
General Availability
not started
Feature List:
- Enable by Default
- Only after all previous stages are checked for bugs
Miscellaneous
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_usernameclaim was missing and was fixed. -
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.
-
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?
-
Here's discussion from october whre somebody uses Authelia as OAuth provider for existing app: github.com/authelia/authelia/discussions/4298
So it seems that it indeed works.
-
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.
-
What have you tried?
-
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.
-
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? -
I've made an enquiry asking this.
