Q: What testing has been performed?

A: During coding, functions were debugged manually using postman and console.log() statements. Postman worked great as a learning tool. At this stage, scope of this development testing was limited to learning how OAuth 2.0 works The primary focus was on grant type: authorization code grant and client credentials grant. Less attention was spent on implicit grant and password grant. Unused grant types can be disabled in the configuration.

In July 2023 Postman became inoperable due elimination of the scratchpad. The postman collections have been removed from the repository. The API tests were re-written using the VSCode extension ThunderClient. In Sept 2024 ThunderClient also became inoperable due to paywall block and the collections have also been removed.

Q: Why add csrf tokens?

A: Cross Site Request Forgery is generally a security issue where the cookie for one web site is used to make a valid data submission to different web site when both pages are using the same web browser.

Csrf protection is the addition of a random csrf token to the html code of a web page html file by the web server before sending the file to the browser. The csrf token can be submitted to the web server with future API requests to reduce the risk of cross-site data submissions.

Csrf protection was primarily added to protect the admin editor <form> elements during critical security actions like creating a new user based on input data entered into the form.

Since it was available, csrf protection was added to the oauth login form, the password change form, and the oauth client trust decision form. This may not be necessary, because the trust decision already includes a random oauthorize transaction code, and both login and password forms require a previously known valid user passwords. Thus, except for the admin editor, adding csrf protection to the oauth forms may be adding complexity and increasing the attack surface without a security benefit. It's currently installed, but may be removed in the future.

Feedback? Suggestions? What is best practice?

Q: Why add express-validator?

Express-validator is an express/node middleware that can provide syntax validation to user data submission before action by additional request handlers. Syntax errors in user input will generate a status 422 Unprocessable Entity.

The primary purpose was to sanitize user input for the admin editor. This is to prevent unsafe command characters from being included in user names, client names, or other string data stored in the database or potentially displayed in a web browser.

Q: Can input validation break oauth?

A: Possibly (see previous question).

Input validation was added to the project to protect the admin editor when creating or editing user accounts. Since it was available, it was added to some of the oauth 2.0 routes.

The oauthorize server (library) appears to have it's own internal input validation. The oauthorize npm repository has large user base and good history. Adding input validation middleware in front of the oauthorize server may be of limited benefit.

Possible issues:

• Prevent automated tests from reaching oauthorize and it's custom callback functions.
• Different grant types require complex syntax rules
• Various oauth data may be optional
• Some oauth data can appear in either body, header, or query parameter
• Possible error responses that are not RFC compliant with Oauth 2.0

It is currently installed on oauth routes, but with limited checks. The input validation includes a custom error handler to generate the "WWW-Authenticate" header in oauth error responses. In the future it may be adjusted or removed entirely from oauth routes.

Feedback? Suggestions? What is best practice?

Q: Are refresh tokens supported?

A: Yes. Refresh tokens can be demonstrated in the development enviornment using Thunder Client. The collection "collab-auth-demo" has folder "Authorization Code Grant" that can be run to obtain an access_token and refresh_token which are stored in Thunder Client variables. In this sequence, step "2H" uses the refresh_token to obtain a replacement access_token.

The collab-frontend demonstration web server supports the use of refresh_tokens. The demo page allows inspection of the token meta-data. After access_token expiration, the refresh_token is used to automatically obtain a replacement access_token. This can be seen by examining the token meta-data on the web page. The property "grant_type" will change from "authorization_code" to "refresh_token"