Add comprehensive SSL support for JVM OpenID Connect clients (Please Dont Merge - Just Review)

[juergmar]

Summary

This PR adds comprehensive SSL/TLS support for JVM implementations of the Kotlin Multiplatform OIDC library, including:

🛠️ Core SSL API Enhancement

• Add JvmSslConfigurer with enhanced HTTP client SSL configuration
• Introduce flexible SslConfig data classes for SSL setup
• Create SslEnabledOpenIdConnectClient wrapper for SSL-aware clients
• Add fluent OpenIdConnectClientBuilder with SSL configuration API
• Support custom trust stores, certificate sources, and SSL contexts

📱 Complete Sample Application

• New desktop-app-with-ssl sample with Compose UI demonstrating SSL scenarios
• Docker setup with Keycloak integration for testing
• Automated certificate generation scripts for development
• Multiple SSL configuration screens (Self-signed, Resources, File-based)
• OAuth flow testing with various SSL certificate sources

📚 Comprehensive Documentation

• 700+ line SSL_EXAMPLES.md with detailed usage examples and setup guides
• Updated README with SSL feature documentation
• Certificate management and troubleshooting guides
• Docker integration examples and security considerations

Breaking Changes

• Removed ACME/Let's Encrypt certificate support (was complex and rarely used)
• Simplified SSL certificate source factory patterns

Test Plan

• SSL sample application builds and runs successfully
• OAuth flows work with self-signed certificates
• Resource-based certificate loading functions correctly
• File-based certificate sources work as expected
• Docker setup with Keycloak integration operational
• All existing tests pass

This implementation focuses on practical SSL use cases while maintaining the library's ease of use and multiplatform compatibility. Its still experimental.

[juergmar]

Any opinions? @kalinjul

[kalinjul]

Hi, thanks for all your work!
From what i understand, you implemented SSL support for the embedded desktop webbrowser.
I guess it is required for some IDP that does not accept http redirect URIs?
Can you explain your use case?

This is a rather large PR and I'm not sure when i find the time to go through it.

[juergmar]

Hi! Thanks for taking a look at this PR. You're absolutely right about the size - I understand it's a lot to review.

Primary Use Case: Enterprise environments where IDPs require HTTPS redirect URIs for security compliance. Many corporate identity providers (especially those following strict security policies) reject HTTP redirect URIs entirely, making the current HTTP-only embedded webserver unusable.

Specific Problem:

• Current library: Desktop OAuth flows only support http://localhost:8080/redirect
• Enterprise IDPs: Often require https://localhost:8443/redirect for security policies
• Result: OAuth flow fails with "Invalid redirect URI" errors

Secondary Use Cases:

1. Custom Certificates: Corporate environments with internal CAs that need custom trust stores
2. Mutual TLS: Some IDPs require client certificates for authentication
3. Security Compliance: Policies that forbid HTTP in OAuth flows entirely

Size Concern: I completely understand the maintenance burden. Would you prefer I break this into smaller PRs? I could start with just:

1. Basic HTTPS webserver support
2. Self-signed certificate generation
3. Simple trust store configuration

The comprehensive sample app and documentation could come later.

No rush - I know you're busy - we all are.

[kalinjul]

Alright, thanks for explaining.
About the client configuration part, is this "just" for your secondary use cases?

What is you strategy in production?
As far as i understand, you will need to have a client certificate which will be delivered together with your Application, so it can be used when hosting the embedded redirect webserver. This certificate would than be public, as it is inside the client app, so it is somewhat useless.
Alternatively, the certificate can be generated and self-signed on the fly (i think you also implemented this).
But the browser will not trust this certificates, right?

And: Am I correct to assume that using https in this context is not about actual security?