Frequently Asked Questions

This page contains a number of frequently asked questions. If your question isn't listed here, feel free to contact us.

The OAuth 2.0 standard consists of many different documents that specify different (often optional) features. The tests on this site are currently based on the following documents:

  • The OAuth 2.0 Authorization Framework (RFC6749)
  • The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750)
  • OAuth 2.0 Threat Model and Security Considerations (RFC6819)
  • OAuth 2.0 Token Revocation (RFC7009)
  • JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC7523)
  • Proof Key for Code Exchange by OAuth Public Clients (RFC7636)
  • OAuth 2.0 Device Authorization Grant (RFC8628)
  • OAuth 2.0 Security Best Current Practice (draft 16)
  • OpenID Connect Core 1.0 incorporating errata set 1
  • OAuth 2.0 Form Post Response Mode
Security countermeasures described in the OAuth specification are accompanied by the keywords must, should, or may. These keywords indicate the requirement levels of implementing said countermeasure. Must requirements are mandatory to implement, should requirements imply a strong preference of being implemented, and may requirements are optional.
OAuch calculates several statistics after each test run. The most important output is the number of unmitigated threats. These threats represent weak points in the implementation, which can be exploited under the right circumstances. The number of partially mitigated threats and deprecated features are the second most important outputs. Partially mitigated threats may or may not be exploitable; OAuch does not report to what degree these threats have been mitigated, only that there is at least one partial countermeasure active. Deprecated features should be avoided if possible, as they are typically deprecated on the grounds of being insecure.
In addition to these three important indicators, OAuch also computes the failure rates of the test cases. This metric is calculated by dividing the number of failed tests by the total number of tests that are executed and converting the result to a percentage. This percentage indicates to what degree a site correctly implements the OAuth specification. An overall failure rate is reported, as well as the individual failure rates of the three requirement levels (must, should, may). The calculation only takes executed tests into account. Tests that are skipped because they are not relevant for the site do not affect the result.
A test run will execute more test cases if the server supports many flows or enables more features. This will increase the number of failed test cases, but will also increase the number of executed tests, keeping the failure rate relatively stable.
To enable users to quickly interpret the results of an analysis, OAuch uses the number of unmitigated threats to calculate a simple A/B/C rating for a site. Sites with zero or one unmitigated threat(s) are assigned an A rating, sites with 5 or less unmitigated threats a B rating, and sites with more unmitigated threats a C rating. This rating is designed to give an immediate impression of how well the tested site is doing.
Not necessarily. Some unmitigated threats may be mitigated on the client-side. However, OAuch does not assume that clients have implemented these countermeasures. It only looks at the countermeasures that have been implemented on the server-side.