OAuth Issuer

The EnderDash OAuth issuer lets a third-party app sign a user in by proving they control a Minecraft account on one of your servers. It speaks OpenID Connect, so most existing OIDC client libraries work without custom code.

The issuer runs at https://oauth.enderdash.com and is separate from the EnderDash dashboard. It never touches a user's dashboard account. It only confirms that someone is logged in to the validation server you picked when you registered the client.

Register a client

OAuth clients are scoped to a single server. Open Servers, pick the server players will log in on, and create a client from its OAuth section. You need owner or admin access on the organization.

A client has:

Field	Notes
Name	Shown to admins. Up to 80 characters.
Redirect URIs	One to sixteen exact `http` or `https` callback URLs. Use `https` outside local development. The `redirect_uri` in a request must match one of these after normalization.

Scopes are not saved on the client record. Authorization requests may use openid, profile, or both, and EnderDash normalizes successful grants to openid profile.

When you save, EnderDash returns a client_id (prefixed edoc_) and a client_secret (prefixed edos_). The secret is shown once. Store it somewhere safe and rotate it from the same screen if it leaks.

Authorization flow

EnderDash supports the authorization code flow for confidential clients. PKCE is also supported when a client sends a code challenge.

Send the user to the /oauth2/authorize endpoint with your request parameters. EnderDash opens the hosted authorize page.
The page shows a one-time challenge code. The user joins the validation server and runs /enderdash login <code> in chat.
Once the server confirms the command, EnderDash redirects back to your redirect_uri with a code and your original state.
Exchange the code at /oauth2/token for an ID token and access token.
Call /oauth2/userinfo with the access token to read the player's claims.

Keep the page open

The user must leave the authorize tab open while they run the command in Minecraft. The page polls for confirmation and redirects on its own.

Endpoints

Discovery is published at /.well-known/openid-configuration, so most clients configure themselves from the issuer URL alone.

Endpoint	Method	Purpose
`/.well-known/openid-configuration`	GET	Discovery document.
`/oauth2/jwks`	GET	Signing keys for verifying ID tokens.
`/oauth2/authorize`	GET	Starts the flow and renders the hosted page.
`/oauth2/token`	POST	Exchanges an authorization code for tokens.
`/oauth2/userinfo`	GET	Returns claims for a valid access token.

Supported parameters

Capability	Values
Response types	`code`
Grant types	`authorization_code`
Scopes	`openid`, `profile`
PKCE methods	`S256`, `plain`
Token endpoint auth	`client_secret_basic`, `client_secret_post`

The /oauth2/authorize request takes response_type=code, client_id, organization_id, redirect_uri, and state. It also accepts optional scope, nonce, code_challenge, and code_challenge_method parameters.

Claims

The ID token and /oauth2/userinfo response identify the verified player, not a dashboard user.

Claim	Description
`sub`	Stable subject identifier for the player on this issuer.
`preferred_username`	The player's Minecraft name.
`minecraft_name`	The player's Minecraft name.
`minecraft_uuid`	The player's Minecraft UUID.
`organization_id`	Organization that owns the validation server.
`server_id`	Server the player logged in on.

Token lifetimes

ID tokens are valid for 10 minutes. Access tokens are valid for 15 minutes. There is no refresh token, so start a new authorization flow when a token expires.

Agent Commands for the enderdash login <code> player command.
Access Model for how organization and server roles work.

Was this page helpful?

Send a quick note if anything is missing or unclear.