DEV Community: Ankit Babbar

Designing OAuth Auth Flow

Ankit Babbar — Sat, 19 Sep 2020 08:56:53 +0000

This articles explores the design of an OAuth2 Auth Flow in decoupled Frontend and Backend application. Get a high level understanding of how OAuth Auth Flow works in 3 legs (Frontend, Backend and OAuth Provider), then use existing libraries or design custom experience without using any libraries. Frontend could possibly a React Application or Angular Application or any other app, Backend app could be written in NodeJS, Go or any language.

Understand the flow

User Authorization Request: From Client App, on a button click, open the Auth Window either in same window using window.location.assign(oauth_provider_auth_url) or in another window using window.open(oauth_provider_auth_url)
- The oauth_provider_auth_url will generally carry the client id, scope, redirect_uri and few other parameters
- This url can be either stored in Client Side or for security purpose this can be obtained from server.
User Authorises Application: The flow will now be handed to OAuth Provider (like Google, or Facebook), where user will approve application to login and grant permission for scope specified earlier.
Authorization Code Grant: After user confirmation, oauth provider issues an OAuth Code, and it redirects to redirect_uri specified earlier with an auth code.
Access Token Request: The Redirect Controller/Page, can now send this request to backend to issue you an access token using the auth code.
Access Token Grant: Server issues the Access Token.

Front End Concerns

Sign In OAuth Button
Redirect page in your application.
- In Development Mode you can provide localhost:[port]/oauth-redirect-uri
- Ngrok is alternative tool which can be used to port forward your localhost and then redirect uri can be specified [your-ngrok-site-url]/[oauth-redirect-uri].
Required action on SignIn - global variable update

Back End Concerns

Obtain the Acces Token from OAuth Provider and issue custom Access Token.

Handling the Auth Code: Backend Sends the Auth Code Sent from the Oauth Redirect Controller in Front End Application to the OAuth provider Access Token Url (with parameters like client_id, client_secret, scope, etc).
On success, OAuth Provider sends a payload that has access token of the OAuth Provider and maybe refresh token and other things.
OAuth Provider Access Token can be wrapped in your custom JWT Token so that you can use it for further request like obtaining profile information.
JWT Token can be sent to Client App to store in its local storage (which can be insecure). Best is to use Http Only Cookie.

PS: Check out my other article on Designing Authentication System

Choosing a Frontend Form Library

Ankit Babbar — Tue, 15 Sep 2020 05:36:46 +0000

Forms are one of the most complex pieces of Frontend Development. In this article we will explore the concerns while selection of Form Library for React or Vue or Angular App.

If the form library, is experimented in tool like Storybook independent of your application code, the complexity arising later can be avoided. Learning from the Continuous Delivery practices, “if it hurts, do it more often, and bring the pain forward”. Therefore prepare a checklist after studying this article and plan effectively the roadmap.

Let's do the Separation of concerns first. Building forms have two types of concerns the Logical concerns (validation, multi value fields, debug errors, etc) and the Presentation Concerns (ease of styling, widgets provided).

Logical Concerns

Validation

Validation is an important concern in selection of any form library. Let us attempt to categorise the types of field validations:

Simple validation: Validation of Field Data Type & RegExp Constrains (like Email, Url, Number, Date, etc)
Complex validation: Dependent Field Validation (where a field is validated dependent upon on other field value) or validation of array of collection of fields.
Async validation: Remote Validation for use cases like unique username validation.

Writing Validation Rules:

Field Level Functions: Validation could be defined at level of each field (like the TextInput can define a prop, say validationFn to check Email RegExp).
Form Data Structure Schema: Library (like yup or joi) allow you to write a schema that validates the whole data structure, including dependent fields.

Multi Value Field Collections

For a use case like Flight Ticket (with list of passengers), a collection of field is required. Ease for adding, removing, shuffling an item/entity in collection must be considered.

Multi Step Form

For a complex use case like Flight Ticket Booking, user may have to go through a journey of multiple forms before the final submission. Multi step forms become complex and ease of shifting steps (possible with animation effect, that is a presentation concern) and maintaining the state in multi steps should be studied, you may also like to use LocalStorage to retain state in case of page refresh or if user by mistake close the tab.

Field Focus and Scroll to Error

For managing Field Focus, or Scroll on First Error after submission and other important use cases where you might need the reference of input element, experiment how this can be accomplished in the selected library.

Dependent Fields and States

Field May become hidden depending upon some other field's value. Getting any field value must be easy at the top level (and in a sub form component that becomes part of main form).

Performance

Needless to say, performance is the most important criteria in complex forms. Jerks in UI when field value changes or field states hide, reflects poor performance in Form, study how best this can be improved.

Debug

For a good Developer Experience (DX), it must be easy to debug field values, fields touched and field errors. How easy it is to get these values and display them in UI (in footer of form or drawer) during development phase is important while building complex forms.

Presentation Concerns

Choosing Form UI Components via a UI Design Library like Ant Design or Material UI solves the Styling Concern. Alternatively you can create custom components library (which can be styled using Styled Components/css/scss). This is hard, author suggest to use some UI Library unless you have very special Design Concerns and can't be accomplished using common UI Libraries.

Many a times an additional component (say FormItem) act as a wrapper for any kind of Input. FormItem can show the label, error message, help message etc, and an input child element. FormItem + Input, may also provided as a single element.

Widgets

Number can be input via sliders, Text Box; Booleans can be input via Switch, Radio, Checkbox. Make a list of widgets required for your presentation and check availability of each and writing a new one from scratch if required like for Drag-n-Drop.

Complex Widgets: Rich Text Editor, file uploads via Dropzone, Video Upload, Select with remote search / tag support may be required. Prepare a checklist of what all is required.

Styling Concerns

Form Item Styling: Styling of label, error message, help text etc in ForItem, maybe you wish to align Label and Input in same line for Desktop and in different lines in Mobile or hide placeholder in Mobile.
Input Styling: Want a Round Checkbox, Want to Change Select Placeholder Font, Border of Text Input... How easy it is to style these components.
Animation: For Multi step forms or Dependent Fields, or Change State of Switch/Checbox, your design can have multiple kinds of animation that you will like to support. Please study the ease of such changes required in the libraries choosen.

Accessibility

Widgets must set accessibility props, like aria-label, aria-required, aria-invalid so as improve Accessibility Support.

(Note: The author has extensive experience in React. The thought process for other frameworks/libraries may be very similar. Suggestion are welcome to improve the article).

Designing Secure Stateless Authentication

Ankit Babbar — Wed, 02 Sep 2020 11:20:08 +0000

We will discuss the high level design for a secure authentication, with important concerns for both backend and frontend. Client Side Application could be written in React or Angular or Vue or any other modern JS Libraries/Frameworks. Backend could be in NodeJS or Go or Php or any language/frameworks your prefer.

Selection of Appropriate Technology

Local Storage and Session Storage are vulnerable to XSS attacks and can be easily read by Injected Scripts, they are also only available in Browser Environment.
In-Memory (i.e. storing it as a global variable like React Context in React App), but it is useful only if the application wants to persist Authentication in a single tab (which will be useful for Banking/Financial Websites).
Cookie Based Authentication Systems are equally vulnerable to XSS Attack or CSRF. But since Cookies are Universal therefore can be chosen for a persistent login which can be made secure.

Security Concerns

HttpOnly Cookie Attribute: HTTP only Cookie prevents the XSS or CSRF Attack. A Http Only Cookie cannot be read by Javascript but it is passed along with your request to your server.
Same-Site Cookie Attribute: For additional Security of Cookie you can specify the Same Site as ‘strict’ which will make sure that Cookie is only passed when the User Hit Your Website from Browser Address Bar. Cookie is no longer available in IFrame.
Secure Cookie Attribute: Cookies in Production Environment must be sent through Https Only. Content-Type Header: By allowing application/json in the content type, prevents CSRF attack.
Rate Limiting DDoS Attack: Backend application must restrict number of login attempts from an IP to prevent the DDoS attack.

Authentication Tokens

A Stateless Authentication generally have two tokens, i.e. Access Token and Refresh Token.

Access Token: Access Token must be short lived and it must be validated in the backend application before proceeding on any operation or data access.
Refresh Token: Refresh Token might be issued to support automatic re-issuing of access tokens.
- Validation: While issuing a refresh token, a record in Database can be created with an expiry, and before issuing a fresh access token, refresh token must be validated.
- Single Time Use: After a single use, refresh token must be deleted and a fresh refresh token should be issued to user for further usage.
- Attack Prevention: An additional mechanism to delete all users tokens or user specific Refresh Token must be available in case of security theft to block the user(s).

How to know if Access Token is expired in Frontend?

While designing the authentication system, either a third cookie (HttpOnly: false) or send response which can be stored in LocalStorage. It can then be read by client side application to decide whether a token must be refreshed before sending the next request. Cookie has the advantage that it is universal and can also be read in SSR Applications. LocalStorage will be restricted to Browser only Environment.

Logout From Application

(Frontend Concern) For implementing a better Logout on the Client Side, it is advisable that a local storage event is fired on Logout and all Tabs Automatically Update their Global Variable and expire Sensitive Information available to a particular user.

References:

https://web.dev/samesite-cookies-explained
https://stackoverflow.com/questions/19867599/what-is-the-difference-between-localstorage-sessionstorage-session-and-cookies
https://security.stackexchange.com/questions/166724/should-i-use-csrf-protection-on-rest-api-endpoints
https://security.stackexchange.com/questions/170477/csrf-with-json-post-when-content-type-must-be-application-json

(HTML forms generated from Backend Application are not part of scope of this article and therefore we don't expand on CSRF Token which is an important security concern for HTML Forms).