To determine if a certain design is “secure”, one must refer to the threat model of the application (which should explain the risk appetite of Party A and Customer X).
But yes, depending on the relationship between Customer X & Party B, one can see at least three potential security threats:
- Spoofing: with the client_id/client_secret pair, Party B can identify as Customer X. This could be totally intended/accepted by Customer X.
- Repudiation: If Party B makes changes on behalf of Customer X, Customer X can’t claim it wasn’t them (or at least, for Party A, in theory, there isn’t a way to clearly know)
- Information disclosure: Party B can garner whatever sensitive information Party A keeps on Customer X
Having said that, usually, Party A has no way to restrict who Customer X shares their token with. This would usually be done through the Terms and Conditions of the service. An example that comes to mind are online budgeting apps that require access to bank accounts to track expenses, and that used to require the user’s banking credentials. This is obviously against most (all?) banks’ T&C, yet many users of said budgeting apps would pass on their credentials anyway.
A bit related, but a common approach that Party A could use, when trying to mitigate the risks above, is to treat Customer X as untrustworthy. This would mean, for example:
- Not use the client_id/client_secret as the only auth factor, and require an additional 2FA
- Clear the token as soon as the behavior of Customer X seems to have changed (either because they are connecting with a different IP/user-agent/etc.)