Two different OAuth uses
Lyra nodes can use Google, GitHub, Discord or Apple as identity providers for human sign-in. That server-side authorization-code flow uses PKCE and one-time CSRF state. It signs a person into Lyra; it does not authorize a third-party application to call the Lyra API.
Delegated third-party access is not public in V1
Lyra does not currently publish an OAuth2 authorization or token endpoint for developer applications. Use Bot tokens for integrations and the normal Lyra session only for first-party human actions. The redirect URI field is reserved for the future delegated flow and must not be presented as active authorization support.
Node sign-in PKCE flow
- GET /auth/oauth/providers lists only providers enabled by the node operator
- GET /auth/oauth/:provider/authorize creates a random state and PKCE verifier stored briefly in Redis
- The provider callback consumes state once, exchanges the code and maps the verified identity
- The browser receives Lyra access and rotating refresh credentials, never the provider access token
Redirect URI safety
Application redirect URIs are validated as absolute HTTP or HTTPS URLs. Plain HTTP is accepted only for localhost development. A future delegated flow must require an exact registered URI match, PKCE S256, short-lived single-use codes and explicit scopes before this field becomes operational.
https://app.example.com/oauth/lyra/callback
http://localhost:5173/callback