So, I read this one Office 365, Azure AD SSO? and this one Enable SSO with OAuth 2 (for Azure AD and Google Apps) and I also think that OAuth authentication via Office 365 / Azure AD could come in very handy. In easy words: I want users to be able to create an account and log-in to Nextcloud with their Office 365 account.
The code behind this route redirects to the auth-endpoint of Office 365, specifying a callback URL
If the user is already logged-in to Office 365, they are redirected to the callback URL immediately, if not, they see the Office 365 login and are redirected afterwards
On the callback URL we need to do the following:
5.1 Decode the user information in form of a json-web-token (easy)
5.2 Make sure the user information we got is complete (easy)
5.3 Verify the user information jwt was signed with an official Azure AD X509 Certificate ā weāll also implement certificate rollover, because we want to cache the certificate, but it can change every x months. (difficult & difficult)
5.4 Find out if the userās domain is in the list of allowed log-in domains (easy)
5.5 Find out if the user (by email) is already in the Nextcloud database. (medium)
5.6 If already there:
5.6.1 Log-in without asking for password (difficult ā for me at least)
5.6.2 Fetch an API token from the correct endpoint with our login-token (easy)
5.6.3 Fetch display name and profile picture from Azure AD, in case they have changed, with API token. (easy)
5.7 If no user like this exists:
5.7.1 Create a new user (difficult ā for me again)
5.7.2 Continue with 5.6.1
Weāll need a configuration interface for following information:
I think what youāre suggesting above is only part of the story. The point of relying on Azure AD (or Google Apps, or any other directory) is that it should completely replace the account system of Nextcloud. That is: we should not use the AAD account to sign in into an existing account in the Nextcloud database. Instead, users should be able to carry their identity, and the Nextcloud user repository would be the AAD directory.
So, Iād say your points 5.5, 5.6 and 5.7 arenāt really necessary: once the user has authenticated via AAD and all points up to 5.4 are valid, then he or she should have a valid session inside Nextcloud.
The next step would be implementing a system that calls the Azure AD APIs every time you need to get, say, a list of users, etc.
This is essentially the same thing that happens when using LDAP with Nextcloud, for example: itās not only used for authentication, but also as a directory.
Idea: the entire Nextcloud auth backend could be rewritten to always rely on OpenID for authentication. So, all local users would be exposed via OpenID only, and authentication mechanisms would become pluggable But thatās not an insignificant amount of work.
PS: Regarding 5.3: there are libraries to do that: check https://jwt.io and search for PHP.
Thanks for taking the time reading my post and responding!
Instead, users should be able to carry their identity, and the Nextcloud user repository would be the AAD directory.
I donāt even know if thatās possible, because you will need to have a user-folder in Nextcloud.
Currently, I donāt see the advantage of making a complicated backend implementation over creating a local user who cannot regularly use log-in, only through OAuth, but has all the benefits of a local user. You could still sync attributes from AzureAD every once in a while.
But maybe weāre not talking about the same things?
PS: Regarding 5.3: there are libraries to do that: check https://jwt.io and search for PHP.
Thanks for the hint, Iāve used the firebase php implementation before, but there might be better choices.
I hear what youāre saying. Essentially, youād use an external provider just to replace the password. It can work and itās definitely easier to implement than my suggestion
What I was thinking was to leverage the AAD directory as the only directory. Sessions would be granted by AAD directly, using JWT tokens. The folder in NC would be created the first time a session for the user is started. There are two advantages that I see here:
Every user in the AAD would be already a user in Nextcloud. No need to create a separate account, so you can share files with all users in the directory.
Once an account is removed from the AAD directory (in a business environment, think termination), the user would lose access to the NC account immediately. Also, it might enable scenarios such as impersonation.
Once an account is removed from the AAD directory (in a business environment, think termination), the user would lose access to the NC account immediately. Also, it might enable scenarios such as impersonation.
This would also be the case with my āFrontendā proposal. If you donāt have an account on Office 365, you canāt log-in, the local account should not be able to log-in without the grant by the OAuth identity provider.
Every user in the AAD would be already a user in Nextcloud. No need to create a separate account, so you can share files with all users in the directory.
I have to admit that this is a huge advantage of implementing a āBackendā, like you suggest. Didnāt think about it before. You might want to share files with users that have never logged-in to Nextcloud before.
Most probably, I wonāt have time to look into this until next year, but Iāll definetly keep you updated here and weāll see then what the best solution will be. Also, itās probably easier if I hit certain questions along the way to ask them once they appear and not all upfront.
line 696 contains a regex that needs to be changed
incorrect line if (preg_match(ā/[^a-zA-Z0-9 _.@-']/ā, $uid)) {
fix if (preg_match(ā/[^a-zA-Z0-9 _.@-'#]/ā, $uid)) {
There is also another issue where nextcloud will complain the username is too long I will find where this exception is being thrown and remove it and share my findings.
This was due to a constant in the file ./lib/public/IUser.php
line 21
I changed the value of MAX_USERID_LENGTH to 68 as the UPN from Microsoft 365 was 67 characters long
)
