To answer your question, I'll refer to the relevant documentation and explain the reasons behind the different callback URLs when forcing PKCE, as well as the potential drawbacks of not forcing PKCE. Regarding the different callback URL when forcing PKCE: According to the [PKCE for Social Sign-in and B2B SSO](https://www.ory.sh/docs/kratos/social-signin/oidc-pkce) documentation, when you set

pkce: force

, you need to use a different redirect URL:

If you set `pkce: force`, you must whitelist a different redirect URL with the OIDC provider: Instead of `https://<slug>.<http://projects.oryapis.com/self-service/methods/oidc/callback/<provider-id|projects.oryapis.com/self-service/methods/oidc/callback/<provider-id>>`, use `https://<slug>.<http://projects.oryapis.com/self-service/methods/oidc/callback|projects.oryapis.com/self-service/methods/oidc/callback>`. Note the missing provider ID and no trailing slash.

The reason for this difference is not explicitly stated in the provided knowledge sources. However, it's likely related to how Ory handles PKCE-enabled flows internally. By using a generic callback URL without the provider ID, Ory can potentially handle PKCE flows more uniformly across different providers. Regarding the drawbacks of not forcing PKCE: PKCE (Proof Key for Code Exchange) is an important security extension for the OAuth 2.0 Authorization Code flow. Not forcing PKCE can lead to several potential security risks: 1. Code Interception: According to the [OAuth2 with PKCE for Mobile Apps and Single Page Apps](https://www.ory.sh/oauth2-for-mobile-app-spa-browser/#choosing-the-correct-oauth2-flow) article, PKCE helps prevent code interception attacks. Without PKCE, an attacker who intercepts the authorization code could potentially use it to obtain an access token. 2. Reduced Security for Public Clients: The [OAuth2 fundamentals](https://www.ory.sh/docs/oauth2-oidc/overview/oauth2-concepts#use-case-examples) documentation recommends using PKCE for mobile apps and single-page applications (SPAs) because they are considered public clients and cannot securely store a client secret. 3. Future Compatibility: The [Why you probably do not need OAuth2 / OpenID Connect](https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/#specs-and-rfcs-deprecate-like-everything-else-in-technology) article mentions that using OAuth2 without PKCE will no longer be an option with OAuth 2.1+. Not using PKCE now might require changes to your implementation in the future. 4. Reduced Protection Against CSRF: PKCE adds an extra layer of protection against Cross-Site Request Forgery (CSRF) attacks by binding the authorization request to the token request. In conclusion, while not forcing PKCE might work in some scenarios, it's generally recommended to use PKCE, especially for public clients like mobile apps and SPAs, to ensure the highest level of security for your OAuth 2.0 flows.