[GH-ISSUE #415] Request: Support authentication using Bearer tokens #397

New issue

Open

opened 2026-02-25 20:31:33 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 20:31:33 +03:00

Owner

Originally created by @martin-hauck on GitHub (Feb 26, 2024).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/415

First, thank you a lot for one of the most useful tools I have installed :-)

Today I stubled across a Confluence installation that supports access to team calendars via CalDav only using an Authorization header with Basic authentication:
Authorization: Basic b64(<username>:<password>)
But sending the Access Token as the password in Basic authentication is not supported

It would be great if CalDavSynchronizer could support Bearer authentication as an alternative to Basic authentication and then send Authorization headers like:
Authorization: Bearer <Access Token>

(I could not find a way to select Bearer auth in the UI. And a search of the source code for "Bearer" only returned one match in the context of the special SwissCom implementation.)

Thanks a lot!
Martin

Originally created by @martin-hauck on GitHub (Feb 26, 2024). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/415 First, thank you a lot for one of the most useful tools I have installed :-) Today I stubled across a Confluence installation that supports access to team calendars via CalDav only using an _Authorization_ header with _Basic_ authentication: `Authorization: Basic b64(<username>:<password>)` But sending the Access Token as the password in _Basic_ authentication is not supported It would be great if CalDavSynchronizer could support _Bearer_ authentication as an alternative to _Basic_ authentication and then send _Authorization_ headers like: `Authorization: Bearer <Access Token>` (I could not find a way to select Bearer auth in the UI. And a search of the source code for "Bearer" only returned one match in the context of the special SwissCom implementation.) Thanks a lot! Martin

kerem commented

2026-02-25 20:31:34 +03:00

Author

Owner

@aluxnimm commented on GitHub (Feb 26, 2024):

Thank you!

Did you try Use Preemptive Authentication instead of Force basic auth in your sync profile/advanced settings/network settings?

@aluxnimm commented on GitHub (Feb 26, 2024): Thank you! Did you try Use Preemptive Authentication instead of Force basic auth in your sync profile/advanced settings/network settings?

kerem commented

2026-02-25 20:31:34 +03:00

Author

Owner

@martin-hauck commented on GitHub (Feb 26, 2024):

I did, but no luck.
Testing using curl and Postman showed that the only thing accepted by the server is a Authorization: Bearer <Token> header.

When no Authorization header is sent with the first request then the server returns 401 with a WWW-Authenticate: Basic realm="https%3A%2F%... header. The Basic actually seems to be incorrect when compared to the observed behaviour.

@martin-hauck commented on GitHub (Feb 26, 2024): I did, but no luck. Testing using curl and Postman showed that the only thing accepted by the server is a `Authorization: Bearer <Token>` header. When no Authorization header is sent with the first request then the server returns 401 with a `WWW-Authenticate: Basic realm="https%3A%2F%...` header. The `Basic` actually seems to be incorrect when compared to the observed behaviour.

kerem commented

2026-02-25 20:31:34 +03:00

Author

Owner

@aluxnimm commented on GitHub (Feb 26, 2024):

And where does the access token come from in your example? Would you need a new config option in the UI where you can enter the token manually?

@aluxnimm commented on GitHub (Feb 26, 2024): And where does the access token come from in your example? Would you need a new config option in the UI where you can enter the token manually?

kerem commented

2026-02-25 20:31:34 +03:00

Author

Owner

@martin-hauck commented on GitHub (Feb 26, 2024):

That would be the idea. I am talking about the kind of API token that you manually generate on a server for a long validity like months or years.
Ideally there would be a toggle to select between User/password (== Basic) and Token only (== Bearer) based authentication with corresponding input fields.

@martin-hauck commented on GitHub (Feb 26, 2024): That would be the idea. I am talking about the kind of API token that you manually generate on a server for a long validity like months or years. Ideally there would be a toggle to select between User/password (== Basic) and Token only (== Bearer) based authentication with corresponding input fields.