Reputation: 1003
When configuring a client to use OpenIdConnect you can specify the clientId, clientSecret, and authority.
Is there an easy way to validate that these are configured correctly?
For authority I can simply check that I get a 200 response from the discodoc (/.well-known/openid-configuration).
But for clientId and clientSecret what is recommended approach to check these are valid and correct against the authority without actually requiring an attempted authentication?
For background I am working to catch misconfigurations in our CI/CD pipelines as early as possible. Issues like clientId not existing in the authority, or clientId existing but clientSecret not being correct, could/should be easily catchable if I can automate these checks.
Upvotes: 1
Views: 869
Reputation: 12352
If your client can perform a client credentials flow then you can make a call to the token endpoint with that flow and see if you get a 200 response. This flow can be performed directly from code and doesn't require any interaction from a user, so you can easily check whether the clientID and secret are valid.
Upvotes: 0
Reputation: 29291
I get the point, since there are quite a few moving parts in an OAuth architecture, and these are the techniques I've used:
SUPPORTABLE ERROR DISPLAYS
During developmemt I intentionally misconfigure settings snd ensure that error displays help to enable fast resolution at any point in time. Eg see the error screenshot in this mobile example.
UI TEST FRAMEWORKS
UI test frameworks such as Selenium can be a good option. Run a nightly login test as a test user account for a production system. If the UI login works you know the client ID and secret are correct.
CODED TESTS
The code flow used by UIs is difficult to test in an automated fashion and UI frameworks are perhaps the best option. If you want to use code, it needs to act like a browser and follow redirects, auto post forms etc. I use this sparingly, since code becomes a little unpleasant, but here is an example.
Upvotes: 2