OAuth 2.0, OIDC and PKCE
Client credentials, consent and legacy flows
Machine identity, public clients and modern security choices.
Understand the concept
Client Credentials obtains access for a machine acting as itself, not a human login. A confidential client can protect credentials on a server. Evaluate application permissions without inventing user ownership. Use rotation, minimal scopes and auditing.
The Resource Owner Password Credentials grant requires giving a password to the application and must not be used under current OAuth security guidance. Prefer supported modern flows over legacy front-channel token patterns, with Code plus PKCE where applicable. An old provider example on the internet is not proof of suitability.
Consent does not remove API authorisation checks. Token audiences, refresh issuance and rotation depend on the provider. Never ship machine secrets in public browser bundles. Back-channel communication needs secure transport and proper client authentication. Review the existing integration before deciding migration details.
When reviewing backend jobs and legacy OAuth integrations.
Treating a client-credentials token as a human user session.
One topic. Three levels of depth.
Backend job → client authentication → access token → permitted APIThe machine acts with its own identity.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
Which human has a nightly report job logged in as?
Show the solution and explanation
No human implied: it can use an application identity.Client credentials does not create a human login.