Authelia as an authorization provider

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.

I've changed sub username email.

Progress. That now logs in the authenticated user from authelia (as long as the email address is not consumed by another user), with some major gotcha's.

1. It will log the user in not mapping either the authelia username or display_name, but rather generating a seemingly random username ( User_XXXX - where XXXX changes with each login)
2. It seems to map this login to the first superuser. Every time. Consequently this superuse login name changes every time and now requires logging in using authelia (luckily I have another superuser to get access to the settings).

Ideally I would like to map the authelia username to the misago user, and the authelia display_name to be what is displayed in as the username in misago (this can be changed in authelia, and is the intended behaviour). This may not be possible, but I mention it as an aside (the alternative would be to log in to misago with the authelia username but be able to change the displayed name in misago).

As another aside, it would be good if misago checked that the user trying to log in is a member of an assigned group - say misago. Some users may be allowed to access some services...but not misago. This should be determined at the auth stage.

It seems that the assignment to the admin user is because when attempting to log in a new user, the email address was set the same as the misago registered admin user.

So.

If I (legitimately) create a user in my authelia instance, and then update the email address to be that of a misago administrator, the auth login in misago maps that new user to afmin user with the same email address. This is very not good!

Clearly the mapping should be based on the username. This is authoritative in the auth single source of truth (authelia) and cannot be changed (unlike the email address).

Logging in as a new username without an email address that has already been consumed, then it correctly assigns a new user...but it does so with the random username as above, rather than username or display_name

name and preferred_username work exactly as described.

That's perfect.

So I can manage my users through authelia. I was going to allow users access to the ldap backend for my users to change usernames and email addresses...but I wont. I will make it on admin request only.

The only issue that I would consider outstanding for me, is checking that the user is a member of the group that allows registration (rather than any member of the auth mechanism). I appreciate that my problem is not your problem, and I can work around it.

Presumably at least one superuser needs to be created first, and then this can be mapped to an authenticating user through the auth? Then other users joining with auth can be assigned as administrators/superusers?

Yes. But I don't think it's possible to log into the admin panel anything other than the "classic" way (at least I don't seem to be able to). That means it's not possible to promote an auth user to admin status...but rather they would have to have a 'classic' admin account created....which couldn't have the same email address, or the consumption of the username would be problematic.

It's messy, but workroundable.

I will. Promise.

That doesn't work. I have tried to do exactly that.

I was unable to promote a user and log into the admin panel in this way.

Worse, having set the password (in misago) I now cannot log in as the corresponding authelia user, and have the name recognised (possibly because it has some legacy of the email address somewhere....deleting the account does not fix it).

It's only that account that I have tried to update to an admin account in the way discussed. All other accounts seem to continue working as before, and new (none admin) accounts join correctly.

This promote to an admin account is the tricky one, and I could do with a working workflow for that.

---Edit---

It seems to be (a fault on my part) that the preferred_username clashed with a name. Resolve that, and it solves the problem. So if I make name, and preferred_username an admin function, then I can avoid the issue.

I just need a way of checking name (once assigned cannot be changed) and preferred_username (can be changed!) never conflict.

Presumably the Presumably the @username within misago addresses the current preferred_username of the user (which can change), but not the name which is possibly unknown to other misago users?

For functionality outside of misago preferred_username can change over time...but this might be problematic for private room ownership/invites etc?

That's all fine. There is a process workflow that makes sense, and can be enforced.

Also I can confirm that user promotion does work where there isn't a username/name clash. So this is all as per my requirements, and I will work on a writeup.

This is problematic not only in the case where the new user hasn't yet logged in (but changes their email address), but also in the case of where a user has logged in, but then subsequently changed their email address legitimately with the auth provider (authelia/lldap in my case).

• Imagine a user has an email address, that subsequently changes for unforeseen reasons (this might be a work email, and they move jobs, or an isp provider that the user moves from, or an email provider service that is withdrawn). The point here being that email addresses may, in some cases, be long lasting. But very often they are not.

• So the user, quite legitimately updates their email address with the auth provider (authelia/lldap).

• Logging into misago now correctly identifies the previously logged in user, and associates the correct account (from the username), however the email address in misago is retained as the incorrect old email address, and there is no way for the user to change that.

• Because the user authenticates with an external service there is no way for a misago adminstrator to change the email address (this is quite correct, but means there is no possible resolution to the previous problem).

In the terms of the authentication provider the name is authoritative and does not change. All other things (email, preferred_name, password) are not authoritative, but their association with the name is managed externally by the auth provider.

With the current status of misago with external oauth that means than there is a serious problem in the event that any user changes their email address. Which is a highly likely event, that happens regularly.

I cannot stress enough. The name is authoritative. The email address is not.