# Check Credentials Programatically Server-Side

**URL:** <https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703>\
**Category:** 💻 Development\
**Created:** [March 19, 2024, 1:59pm UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703 "2024-03-19T13:59:14Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![stellarpower](https://help.nextcloud.com/user_avatar/help.nextcloud.com/stellarpower/32/59936_2.png) [@stellarpower](https://help.nextcloud.com/u/stellarpower)\
**Post date:** [March 19, 2024, 1:59pm UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/1 "2024-03-19T13:59:14Z")

</div>

Hi,

I’m trying to check if a given username/password pair is valid in nextcloud, from a server-side program.

I simply need a true/false query of if the given username or email/password pair is valid from nextcloud - no tokens etc. necessary. This will be running server-side, so I have access to `occ`, PHP, etc. and don’t need to worry abour transferring over the network.

I’d rather not try to query the database myself, but, is there some function I can call into that can verify the given credentials without needing to go via the login page? For now, I am making a dummy DAV request and using the returned code here, but this is probably too slow.

Thanks

---

<div class="post-metadata">

**Author:** ![christianlupus](https://help.nextcloud.com/user_avatar/help.nextcloud.com/christianlupus/32/22699_2.png) [@christianlupus](https://help.nextcloud.com/u/christianlupus)\
**Post date:** [March 20, 2024, 7:34am UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/2 "2024-03-20T07:34:38Z")

</div>

Honestly, I am unsure what the use-case is. Why would you want to do this? The installed mechanisms are in fact already there and tested by means of security.

My first fear was that someone build a trojan, somehow smuggles this into a NC server and brute-forces the passwords.

---

<div class="post-metadata">

**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/6_22734026db12803ebb3e059622ac3534.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\
**Post date:** [March 20, 2024, 9:27am UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/3 "2024-03-20T09:27:34Z")

</div>

[https://docs.nextcloud.com/server/stable/developer\_manual/client\_apis/OCS/ocs-api-overview.html](https://docs.nextcloud.com/server/stable/developer_manual/client_apis/OCS/ocs-api-overview.html)

> [@christianlupus](#):
>
> My first fear was that someone build a trojan, somehow smuggles this into a NC server and brute-forces the passwords.

Once you have admin permissions on the server, it’s a bit late and there are more efficient ways than bruteforce the passwords.  
If you don’t want to rely on passwords alone, 2FA will help.

> [@christianlupus](#):
>
> Honestly, I am unsure what the use-case is.

You are not alone. Like this it sounds a bit like something that should be achieved by other ways.

---

<div class="post-metadata">

**Author:** ![marcelklehr](https://help.nextcloud.com/user_avatar/help.nextcloud.com/marcelklehr/32/25296_2.png) [@marcelklehr](https://help.nextcloud.com/u/marcelklehr)\
**Post date:** [March 20, 2024, 12:42pm UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/4 "2024-03-20T12:42:22Z")

</div>

You can check the nextcloud API over here: [https://nextcloud-server.netlify.app/](https://nextcloud-server.netlify.app/)

This might be what you’re looking for: [Nextcloud PHP API (master)](https://nextcloud-server.netlify.app/classes/ocp-iusermanager#method_checkPassword)

Whether what you’re trying to do is a good idea, you’ll have to decide for yourself.

---

<div class="post-metadata">

**Author:** ![stellarpower](https://help.nextcloud.com/user_avatar/help.nextcloud.com/stellarpower/32/59936_2.png) [@stellarpower](https://help.nextcloud.com/u/stellarpower)\
**Post date:** [March 22, 2024, 12:24am UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/5 "2024-03-22T00:24:52Z")

</div>

I ended up implementing a pull request:

> <https://github.com/nextcloud/server/pull/44335>
>
> \* Resolves: https://help.nextcloud.com/t/check-credentials-programatically-serve…r-side/185703
> 
> \## Summary
> 
> Adds an occ command for checking the password for the given user ID. The user can provide the password literally in the CLI arguments (less secure but other applications don't prevent this), using \`OC\_PASS\`, through stdin or interactively.
> 
> I have a small self-contained application that needs to authenticate users. Rather than maintain a separate set of credentials, or set up something like LDAP (would be overkill), adding a command like this seems the best way to achieve what I needed - the application is server-side and can then look up the user and password, and the exit status is used to determine if the user was authenticated or not.
> 
> 
> Uploading so that the community can benefit from contributions, but please do feel free to pull into a feature branch and rework or modify heavily and use as a springboard. This solved a particular usecase I had so figured may be useful.
> 
> \## TODO
> \- \[\] Tried to make the interactive prompt detect if it's in a TTY or a pipe, but this seems to return true in either case
> \- \[\] People may want to modify this heavily or not add it for security implications for what code is in here. I've thought about some basics, but am not a security expert, nor do I know much about nextcloud's design. I started from the password reset command; so this seems comparable, but someone should review and consider the implications
> \- \[\] I'm by no means a PHP developer, so there may be significant defects.
> \- \[\] Don't have the ability to test against current master; slight modifications and it appears to work on my installed server, running NC 21, but would need to be tested properly against master code.
> 
> \## Checklist
> 
> \- Code is \[properly formatted\](https://docs.nextcloud.com/server/latest/developer\_manual/digging\_deeper/continuous\_integration.html#linting)
> \- \[Sign-off message\](https://github.com/src-d/guide/blob/master/developer-community/fix-DCO.md) is added to all commits
> \- \[\] Tests (\[unit\](https://docs.nextcloud.com/server/latest/developer\_manual/app\_development/tutorial.html#unit-tests), \[integration\](https://docs.nextcloud.com/server/latest/developer\_manual/app\_development/tutorial.html#integration-tests), api and/or acceptance) are included
> \- \[\] Screenshots before/after for front-end changes
> \- \[\] Documentation (\[manuals\](https://github.com/nextcloud/documentation/) or wiki) has been updated or is not required
> \- \[\] \[Backports requested\](https://github.com/nextcloud/backportbot/#usage) where applicable (ex: critical bugfixes)

As I realised after posting this that the occ command for resetting a password implemented all that is needed. And as mentioned, the PHP API turned out to be a lot easier to use than I was expecting.

The use-case is we have a lightweight application on the same server and want people to be able to use the same set of credentials. This application provides for an authentication helper, so I simply plugged this in to call the occ command in the PR.

I am also going on the vein of “admin permissions” - possibly this approach has some holes - but if the container is compromised, then there’s not much to be done, and I have bigger issues to sort!

---

<div class="post-metadata">

**Author:** ![christianlupus](https://help.nextcloud.com/user_avatar/help.nextcloud.com/christianlupus/32/22699_2.png) [@christianlupus](https://help.nextcloud.com/u/christianlupus)\
**Post date:** [March 22, 2024, 8:18am UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/6 "2024-03-22T08:18:59Z")

</div>

No, you are in fact trying to use NC as a Auth provider.

This is perfectly fine. Have a look at [OAuth2](https://oauth.net/2/)! That is the way to go as it is standardized and you could extend with other authentication sources as well. There should be libraries for almost all programming languages available, I guess.  
I think I saw an app that allows to authenticate external services. If not, that would be a valid app but I did not find it in a quick glance.

---

<div class="post-metadata">

**Author:** ![stellarpower](https://help.nextcloud.com/user_avatar/help.nextcloud.com/stellarpower/32/59936_2.png) [@stellarpower](https://help.nextcloud.com/u/stellarpower)\
**Post date:** [March 22, 2024, 2:50pm UTC](https://help.nextcloud.com/t/check-credentials-programatically-server-side/185703/7 "2024-03-22T14:50:35Z")

</div>

> [@christianlupus](#):
>
> you are in fact trying to use NC as a Auth provider.

That’s the aim here. The app receives credentials from the user. I will assume that this app is sufficiently secure - i.e. it has secured the credentials from the client to the point they pop out on the server. It then can slot into different authentication providers rather than use its own database. So I wrote a small helper program that will check against NC and return true if the user is registered. That’s all that is needed in this case, we don’t need to link the accounts more deeply than that.

LDAP, OAuth etc. would be overkill for this situation, although agree in larger scenarios this would probably be more sensible or standardised. It’s also happening server-side; I don’t need these callback flows or to assume the app I’m installing is not trusted to handle the credentials, as is the case with some third-party sites that authenticate with e.g. google or facebook. Also the design of OAuth is the web-based flow, and this won’t work with this application. Users wouldn’t be able to open a browser and follow through getting a token - rather, the username and password pair will be included in requests so I simply want to verify those against the same store in nextcloud rather than maintain a separate one, a little bit like how DAV integration is performed, except that’s within nextcloud’s source and this is coming from a different application container.

Anyway, this works for now, thanks for the suggestions! I have no idea if the PR will prove useful, but it’s there in case someone can benefit from it. There may be more standard usecases where an administrator with access to the server CLI would want to do this, I’m not sure.
