Authentication & Authorization

Single Sign-On

This section is written towards Azure Active Directory login, but all principles apply to any other single sign-on service.

Implementation

Most single sign on providers make use of the OAuth protocol. This is a standardized protocol, resulting in native support from a lot of frameworks. If a single sign on provider has a native support library available, it is required to use this library. As a fallback, native OAuth 2 libraries can be used to communicate with the single sign-on provider.

The Authorization process works in multiple stages. It starts by initiating the flow and obtaining an access and refresh token. These tokens can be used to communicate with the single sign-on service directly, or via the API of the project. Validation of these tokens should always be done using standardized libraries. If such a library is not available, an access token should be verified based on:

  • Its signature
  • AND Its audience
  • AND Its issuer

Access tokens & Refresh tokens

When implementing a single sign-on service, you will obtain an access and a refresh token. When dealing with these tokens, keep the following in mind:

  • Access and refresh tokens used for single sign-on should be stored in the client (e.g., local storage, session storage, device key chains)
  • Access and refresh tokens should be cleared when a user opts to sign out

Roles

For every project, a clear choice should be made whether roles are stored in the single sign-on service or in the application. If roles are stored in the single sign-on service, the roles can be obtained from the access token or fetched using the corresponding API (e.g. the Microsoft Graph API).

Local accounts

Whenever possible, it is recommended to use a single sign-on solution for easy management of accounts, better user experience and faster development time. This section describes guidelines for when it is not possible to use single sign-on.

Implementation

To minimize the risk of a security issue, it is prohibited to use complete custom solutions for authentication and Authorization with local accounts. Always refer to mechanisms provided in the base frameworks that are used for the software project.

Passwords

It is never allowed to store user passwords in plain text, these should always be hashed with one of the following hashing mechanisms:

  • Argon2i
  • BCrypt (minimum cost of 13)
  • SHA-512

All passwords should always be sent over an encrypted TLS connection, both from the user to the application as well as the application to the database, if this database is hosted externally. For more information, consider the section on encryption.

Role-based Access Control (RBAC)

Applications that make use of role-based access control, also known as RBAC, should always check whether the user has the required set of roles for an operation in the backend of the application. An application can never soly check roles in the frontend.

Furthermore, backend frameworks should, if possible, be configured to not grant any user access to an operation or endpoint, when no roles are specified for the operation. By doing so, unintended access to operations and enpoints can be minimized.

Logout

All applications that allow users to login, should provide the option to logout. Any tokens that are still stored (like in the local storage of the web browser), should be cleared.