# Which Problems Are Solved
Some OAuth2 and OIDC providers require the use of PKCE for all their
clients. While ZITADEL already recommended the same for its clients, it
did not yet support the option on the IdP configuration.
# How the Problems Are Solved
- A new boolean `use_pkce` is added to the add/update generic OAuth/OIDC
endpoints.
- A new checkbox is added to the generic OAuth and OIDC provider
templates.
- The `rp.WithPKCE` option is added to the provider if the use of PKCE
has been set.
- The `rp.WithCodeChallenge` and `rp.WithCodeVerifier` options are added
to the OIDC/Auth BeginAuth and CodeExchange function.
- Store verifier or any other persistent argument in the intent or auth
request.
- Create corresponding session object before creating the intent, to be
able to store the information.
- (refactored session structs to use a constructor for unified creation
and better overview of actual usage)
Here's a screenshot showing the URI including the PKCE params:

# Additional Changes
None.
# Additional Context
- Closes#6449
- This PR replaces the existing PR (#8228) of @doncicuto. The base he
did was cherry picked. Thank you very much for that!
---------
Co-authored-by: Miguel Cabrerizo <doncicuto@gmail.com>
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
Adding ability to add a root CA to LDAP configs
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/7888
---------
Co-authored-by: Iraq Jaber <IraqJaber@gmail.com>
# Which Problems Are Solved
UUIDs stored in LDAP are Octet Strings and have to be parsed, so that
they can be stored as IDs as they are not valid UTF8.
# How the Problems Are Solved
Try to parse the RawValue from LDAP as UUID, otherwise try to base64
decode and then parse as UUID, else use the data as string as before.
# Additional Changes
None
# Additional Context
Closes#7601
# Which Problems Are Solved
In case the user bind (user password check for LDAP IdP) fails, there's
no information about what went wrong.
This makes it hard to even impossible to find the cause.
# How the Problems Are Solved
Added logging of the error.
# Additional Changes
Additionally added a log in case no single user (none / multiple) are
found.
# Additional Context
- reported internally
* fix: handling of ldap login through separate endpoint
* fix: handling of ldap login through separate endpoint
* fix: handling of ldap login through separate endpoint
* fix: successful intent for ldap
* fix: successful intent for ldap
* fix: successful intent for ldap
* fix: add changes from code review
* fix: remove set intent credentials and handle ldap errors
* fix: remove set intent credentials and handle ldap errors
* refactor into separate methods and fix merge
* remove mocks
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
Add management functionality for LDAP idps with templates and the basic functionality for the LDAP provider, which can then be used with a separate login page in the future.
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>