So you implemented an OAuth 2.0 API...

While OAuth 2.0 is a good framework for building an API, the spec itself leaves many things un-specified, and it's up to the implementer to make a decision based on their own security requirements. As such, most OAuth 2.0 implementations are not interoperable, which is often cited as a failure of OAuth 2.0. On the other hand, the current state of OAuth 2.0 implementations is that they are often similar enough that developers don't need to learn too many new concepts when dealing with them.

This post documents all the ways in which OAuth 2.0 implementations may differ. All implementations of OAuth 2.0 have made decisions about these things (whether intentional or not), otherwise they are incomplete implementations.

Every place in the spec that mentions things are a "MUST" are assumed to be implemented correctly. In other words, this does not ask you to verify that you implemented required parts of the framework correctly.

Please specify the authorization endpoint and token endpoints. (note: this is only required here if your endpoints are specified in your documentation)

Authorization endpoint:

Token endpoint:

How do clients obtain the location of the authorization and token endpoints? The most common way is to specify them in the API documentation, although an automatic discovery method may be used instead.

Is it possible for the authorization server to ignore (or add) scopes to the values requested during authorization? (For example, giving users the ability to not grant certain scopes requested by the application.) Yes No

Does the authorization server document the default scope if none is specified during authorization? Yes (Documentation URL: ) No

Since the access token request involves sending the user's password to the authorization server, the server must protect against brute-force attacks. Describe what type of protection is used, e.g. rate limiting, sending alerts to the user, etc: