Client IDs and registration

Introducing the printer

The photo service runs a developer console. A developer at the printing company signs in, chooses Register an application, and fills in a form: the application's name, its website, the address your browser should return to, and the kind of access it needs.

When the form is saved, the authorization server assigns the application a client ID:

Client ID: photo-printer
Client type: confidential
Redirect URI: https://printer.example/oauth/callback
Grant types: authorization_code, refresh_token
Scopes it may request: photos.read
Client authentication: client_secret_basic

The client ID is how the printer names itself in every request. It appears in authorization URLs, so it passes through browsers, history, and server logs. That is fine, because a client ID is an identifier, not a credential. Knowing photo-printer lets someone write a request that claims to come from the printer. It does not let them prove that claim. As the Foundations lessons explained, a confidential client proves its identity with a separate credential, and a public client has no such proof to offer.

The value is unique only at the authorization server that issued it. photo-printer means something to the photo service. Another service that the printer also uses would issue its own client ID, perhaps a random string such as 8f3c21e9-6b4d-4a1f-9e2c-5d07b8a4c613, and keep its own registration.

What a registration records

The summary above is more than paperwork. Each line becomes a rule the authorization server applies.

The client type tells the server whether to expect client authentication. The redirect URI limits where authorization responses may go. The grant types list the ways this client may obtain tokens, so a request from photo-printer using the device authorization grant would be refused, even if everything else about it were correct. The scopes limit what the client may ask for at all, before any person is asked to approve it. The authentication method says how the client will prove itself, and the server holds whatever it needs to check that proof.

Registration therefore decides what a client is allowed to attempt. Each request still has its own checks: you can refuse consent, the photo service can apply policy, and the API can reject an operation. But a request that falls outside the registration never reaches those decisions. The server rejects it because this client was never set up to make it.

The record also gives the photo service a place to act. It can suspend a client that misbehaves, which stops new authorization requests and token requests from that client. It can list the people who have connected a client, show a client's name on your account's list of connected applications, and remove its access in one place.

One application, several clients

The printing company does not have just one piece of software. It has the website's backend, a phone app, and the scheduled job that talks to the print lab. It also runs a test copy of the website where developers try changes before releasing them.

It is tempting to register "the printer" once and share that registration everywhere. That would blur exactly the things registration is meant to keep precise.

The website's backend is a confidential client that can keep a secret. The phone app is a public client that cannot. Given one shared registration, the photo service could not tell which one was asking, and it could not require client authentication from one without breaking the other. The test website has its own return address, on a test domain, which should never be accepted for the real service. And if the phone app's client ID were ever abused, the printing company would want to suspend that client alone, not its website as well.

So each deployment with different credentials, return addresses, or permissions gets its own registration and its own client ID. Your account might list them under one name, Photo Printer, while the authorization server treats them as separate clients with separate rules.

A developer filling in a form is the most familiar way to register a client, but it is not the only one. An administrator can create registrations for an organization's own applications, and some services let software register itself through an API. Advanced OAuth will cover that dynamic registration. Whichever way a record is created, the result is the same kind of record. The next lesson looks at two parts of it in detail: the return addresses a client may use, and the information it shows to people.