The website presents a "Sign in with Central Archives" button.
The user clicks the button.
The website redirects to the authorization endpoint, requesting the wildcard scope idp:character:?.read.
Central Archives presents the user with the consent screen, letting them choose the character to sign in with.
Central Archives redirects back to the website, granting it the scope matching the user's selected character, e.g. idp:character:12345678.read.
The website calls the Character API to read the list of accessible characters, which will consist of the single verified character the user wants to sign in with.
Website, user authentication
The website presents a "Sign in with Central Archives" button.
The user clicks the button.
The website redirects to the authorization endpoint, requesting the scope user.read.
Central Archives presents the user with the consent screen.
Central Archives redirects back to the website, granting it the scope user.read.
The website calls the User API to read the Central Archives user ID, and remembers it while presenting its own account creation form. If it has the user email from the idp:user:email.read scope, it can pre-fill that.
In the future, when the user clicks "Sign in with Central Archives" and is redirected back with the already known Central Archives user ID, the website will use this user ID to sign them in with their existing user account.
Plugin, character authentication
The user is playing the character John Finalfantasy (Midgardsormr) in-game. The plugin wants to log in to its own server and prove that it's acting on this character's behalf.
The plugin contacts its server, which creates a session (which will now be associated with this particular plugin client) and sends an authorization URL to open in the user's browser on the plugin server's behalf.
The plugin client opens the provided URL in the user's browser.
The user authorizes the request via the opened consent screen.
Central Archives redirects to the plugin server, granting it access to a scope based on the character's Lodestone ID, e.g. idp:character:12345678.read.
The plugin server calls the Character API with this access token, verifies that the returned character is indeed John Finalfantasy (Midgardsormr), and marks the session started by the plugin client as authenticated with that character.
The plugin server notifies the plugin client that the login process is complete and it can make authenticated requests to the plugin server using its session.