In the README I offered a Security Best Practices section regarding the storage of confidential OAuth client_id + secret_id information.

Although the client_id is public and the client_secret is sensitive and private it is still widely regarded that both of these values should be treated as confidential.

This section always seems to get the most reactions in forums saying it's not the best practice, but no one seems to offer any clear and better alternatives that satisfy the use case requirements for when a mobile device or application acts as the OAuth client to communicate with an Authorization/Resource Server.

It's widely understood that mobile apps present their own challenges when storing client_id and client_secret values because it is possible for someone to inspect and reverse engineer the contents of your app and look at any files inside your app bundle.

Options

1) Build OAuth Providers Programmatically via CI Build Pipeline (Suggested)

Almost all continuous integration and continuous delivery platforms have the ability to generate source code during build workflows that can get compiled into Swift byte code. It's rather trivial for a developer to write a step during this process that generates a .swift file that provides access to a list of OAuth.Provider objects that have their confidential values set from the secure CI platform secret keys. This swift code is then compiled into the application as byte code.

Benefits:

• Swift code is compiled into machine code (bytecode) that the processor can understand and execute directly. The original source code is not embedded within the compiled application. In practical terms, the security and obfuscation inherent in compiled languages make extracting confidential values difficult (but not impossible).

However, there are techniques that could potentially give you some insight:

• Reverse engineering: Sophisticated reverse engineering tools could be used to analyze the compiled bytecode. This is a complex process and unlikely to yield the original source code or reliable property values.
• Memory analysis: At runtime, you might be able to use a debugger or other tools to inspect the program's memory and potentially identify the memory locations where property values are stored. However, this is advanced and depends on the specific code and execution environment.

2) Bundle an oauth.json file into the app (Not suggested)

The security risks here are fairly evident (as described above) and can't be overlooked.

3) Only allow PKCE Workflow

Another potential solution here is to ONLY offer the PKCE solution because it doesn't require a client_secret.

However, removing the Authorization Code, Device Code, and Client Credentials flows limits the usage (and value) of this Swift Package for developers who understand the risks and simply need a plug-in OAuth lib to handle their use cases.

Or? ...

Expert Security Advice 🙏

It would be great to get advice and feedback from a true mobile security expert here who understands the use cases.