Implementation instructions

Client Registration https://tools.ietf.org/html/rfc6749#section-2

Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve end-user interaction with an HTML registration form.

Client registration does not require a direct interaction between the client and the authorization server. When supported by the authorization server, registration can rely on other means for establishing trust and obtaining the required client properties (e.g., redirection URI, client type). For example, registration can be accomplished using a self-issued or third-party-issued assertion, or by the authorization server performing client discovery using a trusted channel.

When registering a client, the client developer SHALL:

o specify the client type as described in Section 2.1,

o provide its client redirection URIs as described in Section 3.1.2,

o include any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms).

Client Password https://tools.ietf.org/html/rfc6749#section-2.3.1

The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication.

Use High Entropy for Secrets https://tools.ietf.org/html/rfc6819#section-5.1.4.2.2

Since this client authentication method involves a password, the authorization server MUST protect any endpoint utilizing it against brute force attacks.

When creating secrets not intended for usage by human users (e.g., client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the authorization server.

Authorization Endpoint https://tools.ietf.org/html/rfc6749#section-3.1

Since requests to the authorization endpoint result in user authentication and the transmission of clear-text credentials (in the HTTP response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the authorization endpoint.

Endpoint Request Confidentiality https://tools.ietf.org/html/rfc6749#section-3.1.2.1

The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers. If TLS is not available, the authorization server SHOULD warn the resource owner about the insecure endpoint prior to redirection (e.g., display a message during the authorization request).

Lack of transport-layer security can have a severe impact on the security of the client and the protected resources it is authorized to access. The use of transport-layer security is particularly critical when the authorization process is used as a form of delegated end-user authentication by the client (e.g., third-party sign-in service).

Endpoint Content https://tools.ietf.org/html/rfc6749#section-3.1.2.5

The redirection request to the client's endpoint typically results in an HTML document response, processed by the user-agent. If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full access to the redirection URI and the credentials it contains.

The client SHOULD NOT include any third-party scripts (e.g., third- party analytics, social plug-ins, ad networks) in the redirection endpoint response. Instead, it SHOULD extract the credentials from the URI and redirect the user-agent again to another endpoint without exposing the credentials (in the URI or elsewhere). If third-party scripts are included, the client MUST ensure that its own scripts (used to extract and remove the credentials from the URI) will execute first.

Token Endpoint https://tools.ietf.org/html/rfc6749#section-3.2

Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the token endpoint.

Authorization Request and Response https://tools.ietf.org/html/rfc6749#section-4.3.1

The method through which the client obtains the resource owner credentials is beyond the scope of this specification. The client MUST discard the credentials once an access token has been obtained.

Access Token Response https://tools.ietf.org/html/rfc6749#section-4.3.2

The authorization server MUST protect endpoints utilizing the resource owner's password against brute force attacks (e.g., using rate-limitation or generating alerts).