Apex callout to an OpenID Connect endpoint protected by PKCE code challenge

Question

I'm trying to write Apex code that'll call an external API. The API is using OpenID Connect for authentication, meaning I'll have to first give consent in order to get an authorization code, then exchange that for an access token and THEN use that as Bearer token to call the actual API endpoint I want. The entire flow is described on this page: https://developer.mobilepay.dk/developersupport/openid-get-started

Normally, I would use Named Credentials for easy callouts, however in this case, the authorize- and token-steps are using PKCE code challenge, which means I'll have to add at least one extra header to calls to the authorize endpoint (the codechallenge) as well as to the later calls to the token endpoint (the codeverifier). I cannot see any way of using Named Credentials - or Auth. Providers - to do this.

I also tried looking into storing tokens in Custom Metadata, but that won't work since I cannot DML Custom Metadata and each access token is only valid for 5 minutes before expiring and needing the refresh token, so I'd need some automated way of refreshing it.

What would be the most sensible way to accomplish this? All the documentation I can find about Salesforce + OpenID is talking about how to use OpenID providers to log INTO Salesforce, but I'm attempting to go in the other direction: Using OpenID to call OUT of Salesforce to a third-party API.

Answer 1

1. You'll need to roll your own client that implements the oAuth authorization code flow with PKCE extension. As you found out, Named Credential won't help you.

2. The common wisdom is that tokens should be stored in custom settings and/or custom metadata. The latter can be updated via the Metadata API. You will also need to store the code verifier until it's redeemed for the access token, platform cache might be a good option.

We disagree with the common wisdom. Our recommendation is that tokens (and any intermediate material such as code verifier) should be managed as fields on records via a custom object. You can encrypt fields, manage access to these records based on the usual Salesforce machinery, keep the records for audit purposes and/or purge them as needed, report on them and so on.