How to Authenticate to the WebDAV API?

Server configuration

Operating system:
Debian 11

Web server:
Nginx 1.18.0

ownCloud version: (see ownCloud admin page)
Infinite Scale 2.0.0-rc.1

Updated from an older ownCloud or fresh install:
Fresh Install, Binary Setup

I am attempting to integrate 3rd party software to allow creation of folders and uploading of files into my Owncloud Infinite Scale server. Pouring over the documentation, I have found endpoints for performing these actions with WebDAV API commands.

My difficulty is in authenticating to this API. It is using OpenID Connect as far as I can tell. I have been unable to locate any documentation on the endpoints to use for authenticating and receiving my access token so I can make the desired API calls.

I’ve been able to get API calls to work by scraping an access token out of a browser session. It appears OpenID Connect typically uses a browser for a user to input their credentials. As this will be a system authenticating and not a person, this is not a flow that will work for my use case.

Is there documentation that someone can point me to on how to authenticate against this API or setup an API client that uses an API key or something?

I appreciate any help that can be offered.

App passwords / tokens for 3rd party WebDAV access are on the roadmap:
App Passwords / Tokens for legacy WebDAV clients · Issue #197 · owncloud/ocis · GitHub

There is oidc-agent which makes oidc more usable from the cli.

See the rclone docs as an example how to use it: WebDAV (

Or for curl: General Usage - oidc-agent (

I appreciate your responses. I’ve installed the oidc-agent and have been working with that to get authenticated. I’ll have to do some pretty wild work arounds to get all this working, but I think I’ll be able to get there. It sure would be nice if OCIS would provide an API for file operations with more machine usable authentication flow. I’m glad app passwords are on the road map.

Thanks again for pointing me in the right direction.

1 Like

It would be awesome if you could share notes about the process you went to, maybe others can benefit from that as well?

Whatever form you like…



Using an external fully featured IDP like Keycloak might solve the issue (or make it less painful), but I fully agree that the default oCIS internal IDP is pretty hard to use if you want to work with the API. Not only that the feature set quite limited, also the documentation is non-existent and users have to read the code… Here is what I have done to obtain an OIDC access token from the command line in a non-interactive way:

## Login with a username/password to get an OIDC session. Im going to use a default demo user "einstein/relativity". Username and password need to be replaced. A successful request returns a JSON.

curl -v -b /tmp/ocis.txt -c /tmp/ocis.txt -X POST "" \
    -H "Origin:" \
    -H 'Kopano-Konnect-XSRF: 1' \
    -H 'Content-Type: application/json' \
    -d '{"params":["einstein","relativity","1"], "hello": {}}'

  "success": true,
  "state": "",
  "hello": {
    "state": "",
    "flow": "",
    "success": true,
    "username": "einstein",
    "displayName": "Albert Einstein",
    "branding": {}

## Request an access token using the active OIDC session. The access token will be returned as URL parameter of the `location` Header and need to be extracted by some bash magic or copied manually.  CAUTION: The default lifetime of an access tokens is `expires_in=300` (5min) which is quiet short if you have to maintain it manually. 

curl -LIs -b /tmp/ocis.txt -c /tmp/ocis.txt -G ""  \
    --data-urlencode "scope=openid profile email" \
    --data-urlencode "response_type=token" \
    --data-urlencode "client_id=web" \
    --data-urlencode "redirect_uri=" \
    | grep "location:"


## The token from above can be used to access the API.


curl -s -X GET   ''   -H 'accept: application/json'   -H "Authorization: Bearer $token" | jq
  "displayName": "Albert Einstein",
  "id": "4c510ada-c86b-4815-8820-42cdf82c3d51",
  "mail": "",
  "onPremisesSamAccountName": "einstein"

## Discover the personal spaces WebDAV uri

❯ curl -s -X GET   ''   -H 'accept: application/json'   -H "Authorization: Bearer $token" | jq
  "value": [
      "driveAlias": "personal/einstein",
      "driveType": "personal",
      "id": "166d1210-cdb9-50ab-9f1e-ecb9ef12a304$4c510ada-c86b-4815-8820-42cdf82c3d51",
      "lastModifiedDateTime": "2022-12-03T12:11:43.401852121Z",
      "name": "Albert Einstein",
      "owner": {
        "user": {
          "id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
      "quota": {
        "remaining": 28486905856,
        "state": "normal",
        "total": 0,
        "used": 0
      "root": {
        "eTag": "\"2e7875997c6020906bd0bcd449ce1cf9\"",
        "id": "166d1210-cdb9-50ab-9f1e-ecb9ef12a304$4c510ada-c86b-4815-8820-42cdf82c3d51",
        "webDavUrl": "$4c510ada-c86b-4815-8820-42cdf82c3d51"
      "webUrl": "$4c510ada-c86b-4815-8820-42cdf82c3d51"

## Upload a file. CAUTION: The target filename need to be passed to the URL, otherwise the upload will fail with a HTTP 500.

curl -X PUT  '$4c510ada-c86b-4815-8820-42cdf82c3d51/' -H "Authorization: Bearer $token" --data-binary @/tmp/

All in all, this process is more a hack than a stable API interaction.


There was a wrong cookie path used in the authorize curl command. I have fixed it now and improved the URL parameter handling as well.

Is there anything else to be considered? I spend hours on trying to access the webdav api with the bearer token - be it with rclone or with curl as shown by you.

Token generation and the request to the graph api works but when I try to access the webdav api, I get a http code 401 or 404 depending on the webdav url I choose.

With basic auth all works fine.

The Token has a very short Time to live.

Oidc agent is exactly for that purpose, to keep the token refreshed.

Unfortunately OIDC is creating some barrier to use it for machine to machine communication.

Addition regarding the default Idp in ocis Try to ship Authelia as the default IdP in the ocis binary

I forgot to mention that I also configured rclone to work with oidc-agent but had the same problem.