Client Credentials
Client trades its own credentials for a token, acting on its own behalf.
Designed for trusted system <-> system communication without requiring any user interaction.
Uses only
back-channelcommunication.
Flow In Action
Machine A stores the Client ID and Client Secret (make sure to dynamically fetch the respective credentials at runtime and not hardcode them).
Machine A reaches out to the Authorization Server with the Client ID and Client Secret.
Authorization Server returns Machine A an access token.
Machine A can now use the Access Token with the Resource Provider to access protected resources.
Sometimes referred to as two-legged OAuth because there is no user involved in the flow unlike other grant types. See Supporting Terminology for other types of "legged" examples.
Last updated