This entire section of the wiki is entirely tentative! While it is unlikely, everything is still subject to change.

Flashii uses a mix of OAuth 2.0, the experimental OAuth 2.1 and some components of OpenID Connect to provide authentication and authorization for third-party applications. Being that OAuth is a framework, certain things have been omitted and other things have been augmented where it makes sense, but at a basic level there should be no incompatibilities. The average existent OAuth 2.0 client library should be able to interact with our server implementation without issue.

Because OAuth has its own expected characteristics in how responses and requests are formatted, it is entirely separate from the actual Flashii API. Despite that, as of Version 1 of the Flashii API, the only major difference is the way errors are formatted.

For reference, a list of supported standards and drafts. The documentation on the wiki will cover everything you need to know specific to Flashii so you won't have to worry about this, but they're here if you're interested or in case there happen to be gaps in the documentation.

• RFC6749: The base OAuth 2.0 authorization framework specification.
  • RFC8996: Deprecation of TLS 1.0 and 1.1, mostly as a result of server configuration.
  • RFC9700: Redirect URIs are validates against a known list; PKCE is available and required when not explicitly operating in OAuth 2.0 backwards compatible mode; Implicit and Resource Owner Password grants are omitted entirely; DPoP is not implemented at this time but may come in the future as an option.
• RFC7009: An endpoint for revocation of access and refresh tokens is provided.
• RFC7662: An endpoint for introspecion of access and refresh tokens is provided.
• RFC8414: An endpoint with up-to-date metadata about the authorization server is available and should be used if possible. Certain fields specific to OpenID Connect are also included as the same output is used for the OpenID Metadata endpoint, both paths are provided for compatibility reasons.
• RFC8628: Device Authorization Grant for clients that are not able to spawn a web browser window is available.
• RFC9728: An endpoint with up-to-date protected resource information is available and may should additionally be used to resolve the authorization server.
• draft-ietf-oauth-v2-1-13: A best-effort to implement OAuth 2.1 is made, but for compatibility with existing libraries and services an implicit downgrade to OAuth 2.0 behaviour is done where it doesn't compromise security too much. This may become a developer toggle in the future.
• OpenID Connect Core 1.0: Provided for retrieving user info in a more universally standardised manner. Flashii API native alternatives may be available.
• OpenID Connect Discovery 1.0: Both the aforementioned OpenID discovery endpoint and WebFinger endpoint for user lookup are available.

There are likely things I forgot to include in this list, as standards tend to depend on other standards themselves.