The paper focuses on authentication and authorization in public clients and provides a secure model as an alternative to costly Microsoft Duende BFF solution. After giving a brief overview of confidential and public clients in terms of authorization, we have analyzed problems and potential attack vectors associated with the authorization process in public clients due to their inability to hold credentials securely. Confidential clients are implemented on secure servers or able to facilitate secure authentication by other means, while public clients lack this security. Our research discovered algorithms, models, and methods for secure authorization in public clients. As a part of our model, we have implemented high entropy Proof Key for Code Exchange generator in C# .NET 6.0. In addition, we have provided a solution to a problem of storing sensitive information in public clients using the Backend for Frontend concept. This concept leverages a reverse proxy pattern where a backend application acts as a proxy and handles all client requests. Having a proxy backend application significantly tightens security model for public clients, while restricting possible attack vectors. The authorization model being researched was based on Proof Key for Code Exchange and Backend for Frontend approach. During the testing phase of our research, we have confirmed that the model was not vulnerable to Cross-Site-Scripting and Auth Code Interception attacks. A sequence diagram outlining main actors and interactions among them in context of authorization has been designed. The diagram stands as the visual representation of the model that uses proposed methods and algorithms. As a result, we have managed to build an alternative to secure authorization solutions for public clients that do not rely on the client secret. We have summarized our key findings in a Blazor Web Assembly application, which is classified as public and uses the described authentication model via a shared library.
According to OAUTH 2.0 specification [
Confidential clients store their secret in code or configuration file. However, public clients can not
store a secret without revealing it to unauthorized parties. For example, in mobile applications it is not
possible to keep a secret in code because an attacker could retrieve it via a de-compilation process. In
addition to that, mobile apps are vulnerable to what is called an Auth Code Interception Attack [
In this example, an attacker registers an additional address via a Malicious App to intercept redirected requests and leverages an ability to intercept an authorization code from the auth server. This example closely resembles a classic Man-In-The-Middle attack and could be viewed as a variation of such. While this particular attack is only feasible for mobile apps, SPA also cannot use a client secret because their entire code is accessible through a browser.
From the moment of publication of OAUTH 2.0 specs in 2013, the specification has become
widely popular and has been adopted by key industry players such as Facebook, Twitter, and Google,
practically becoming a standard [
OAUTH 2.0 security best current practice [
Considering problems stated above, specification OAUTH 2.0 proposes to use PKCE algorithm
[
Basic authorization model with PKCE algorithm can be broken down into the following steps: a) Client generates code_challenge and code_verifier; sends an authorization request that includes code_challenge and code_challenge_method. b) Authorization server saves code_challenge together with the method and sends an authorization code back to client. c) Client sends a request for an access token and includes the auth code with code_verifier. d) Auth server checks code_verifier against a stored code_challenge and returns an access token in case the verification was successful.
This algorithm works successfully because even if attacker manages to intercept the auth code, it is impossible to exchange the code for an access token without code_verifier, which prevents Auth Code Interception attack displayed on Pic. 1. Worth mentioning that a pair of code_challenge and code_verifier must be unique and valid for one time use only. It is equally important to store code_verifier securely between authorization and access token requests. We dedicated a chapter “Methods of storing code_verifier in public clients” to solving this problem. In addition, a client has to use a TLS secure channel for data transfer.
For generation of code_verifier and code_challenge a class named PkceGenerator was created, which has methods GenerateCodeVerifier and GenerateCodeChallenge respectively. A constructor of this class accepts a parameter representing the size of code_verifier. A minimum size is 43 symbols while maximum is 128 according to the OAUTH 2.0 specification. C# .NET 6.0 with System and System.Security.Cryptography assemblies was used for developing this class. namespace DemoApp.Authentication { /// <summary> /// Provides a randomly generating PKCE code verifier and it's corresponding code challenge. /// </summary> internal class PkceGenerator { /// <summary> /// The randomly generated PKCE code verifier. /// </summary> public string CodeVerifier; /// <summary> /// Corresponding PKCE code challenge. /// </summary> public string CodeChallenge; /// <summary> /// Initializes a new instance of the Pkce class. /// </summary> /// <param name="size">The size of the code verifier (43 - 128 charters).</param> public PkceGenerator(uint size = 128) { CodeVerifier = GenerateCodeVerifier(size); CodeChallenge = GenerateCodeChallenge(CodeVerifier); } … } }
According to OAUTH 2.0 RFC-7636 specification, code_verifier must be a cryptographically strong high-entropy string with length from 43 to 128 symbols. Accepted symbols are A-Z, a-z, 0-9, -, ., _, ~. Proposed implementation compliant with specs can be found below. /// <summary> /// Generates a code_verifier according to RFC-7636. } } /// </summary> /// <param name="size">The size of the code verifier (43 - 128 charters).</param> /// <returns>A code verifier.</returns> public static string GenerateCodeVerifier(uint size = 128) { if (size < 43 || size > 128) size = 128; const string unreservedCharacters = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~"; Random random = new Random(); char[] highEntropyCryptograph = new char[size]; for (int i = 0; i < highEntropyCryptograph.Length; i++) { highEntropyCryptograph[i] = unreservedCharacters[random.Next(unreservedCharacters.Length)]; } return new string(highEntropyCryptograph);
Code challenge is created by hashing code_verifier using a SHA256 algorithm. A method presented below hashed code_verifier with SHA256 and replaces unacceptable symbols making the value usable in a URL (doing a so-called URL Encoding). /// <summary> /// Generates a code_challenge according to RFC-7636. /// </summary> /// <param name="codeVerifier">The code verifier.</param> /// <returns>A code challenge.</returns> public static string GenerateCodeChallenge(string codeVerifier) { using var sha256 = SHA256.Create(); var challengeBytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(codeVerifier)); return Convert.ToBase64String(challengeBytes) .Replace('+', '-') .Replace('/', '_') .Replace("=", "");
Using this class in the application code is fairly straightforward: developer has to create an instance of this class and access an appropriate property to get code_verifier or code_challenge value. Simple and lightweight design of the class ensures proper usage. An example is presented below. PkceGenerator pkceGenerator = new (); string codeVerifier = pkceGenerator.CodeVerifier; string codeChallenge = pkceGenerator.CodeChallenge;
Developers need to keep in mind that each pair of generated code_challenge and code_verifier must be used only once to ensure security. Applications should not attempt to utilize the same pair of codes because it could lead to potential interception and unfair usage of such codes by attacker in a pursue to retrieve an auth code. OAUTH 2.0 specification and RFC-7636 do not provide any information or best practices regarding code_verifier storage, so in the next chapter we are set to outline main methods of storing code_verifier in applications because it is fundamental to PKCE authorization flow.
As it was stated before, PKCE algorithm specification does not propose any methods of storing
code_verifier in between requests. Due to the fact that client receives an auth code via a callback, it is
not possible to save code verifier in a variable or by other means in code. We are going to examine
methods for storing code_verifier value in terms of WEB-applications (React, Angular, Web
Assembly). Additional methods of secure data storage for Android [
Browser storage is the most obvious solution when dealing with information storage in
WEBclients. There are two types of storage in a browser: Local Storage and Session Storage [
Pros of storing a value in browser storage: - Quick read/write operations via native browser API. - Easy implementation with JS.
Cons of such approach: - Vulnerable to XSS attacks. - Potential for a data leak.
It is worth mentioning that modern frameworks such as Angular and React do a fair share of work and provide methods for protecting against XSS-attacks. Nevertheless, there is always a possibility of sensitive data leak when this data is being stored in a browser. 5.2.
Another approach to information storage in a browser are cookies [
Server applications are able to set cookies in response to a client, which cannot be retrieved via
JavaScript. Such cookies are added to a response with HttpOnly flag [
Pros of Server cookies approach: - Makes XSS attack impossible if configured correctly. - The most secure method for storing sensitive information.
Cons of this approach: - A backend service hosted on the same domain as the client is mandatory in order to set
HttpOnly cookies with SameSite.Strict attribute. - Deployment process could become complicated because it is required to deploy both a client and a server application.
6. Authorization server directs a user to a login page where the user enters credentials and provides consent. 7. Authorization handles the login result, saves code_challenge, and generates auth_code. 8. Authorization server redirects request back to return_url adding an auth_code. 9. Client sends a POST request to BFF for authorization token adding an auth_code to request parameters. 10. BFF reads code_verifier from cookies, adds code_verifier and auth_code and calls authorization service to get a token. BFF can delete code_verifier from cookies at this point. 11. Authorization server verifies code_verifier against stored code_challenge, auth_code and other parameters such as requestor’s IP address. 12. After a successful verification, auth server issues an auth token and sends it back. 13. BFF receives authorization token, writes it in cookies as HttpOnly, Secure, SameSite.Strict. 14. BFF returns successful result to a client application. 15. Client requests user’s information via BFF and restores state.
Authorization flow is depicted in details on Figure 3.
Therefore, after successful authorization, a client is authorized to call protected BFF methods
designated for authorized users only. At the same time, a client does not contain any sensitive
information which could be vulnerable to XSS-attacks. Secure data such as code_verifier or
authorization token is stored in HttpOnly cookies with SameSite.Strict as presented in the chapter
above. In this model BFF acts as a reverse proxy pattern [
In order to ensure code reusability and scalability of this project, we have built a shared library, which uses our proposed model. This common project handles authentication and authorization for .NET Core API and Blazor applications. Our library can be packaged as a NuGet package and distributed via Azure Artifacts or similar package distribution platform. Customers will simply install the necessary packages in their projects, complete the configuration, and be able to facilitate secure authentication in public single-page applications. This paragraph provides an overview of the library as well as configuration that is required for the setup. 7.1.
Our shared library is called BFFLight and it consists of two projects: BFFLight.Wasm and BFFLight.Server.
The first project – BFFLight.Wasm has all necessary classes and extensions to setup secure authentication in Blazor Web Assembly client application. Project’s structure is the following: Authentication (folder with authentication interfaces, classes, and models) o ProfileResponse.cs (model for user’s info response) o BFFLightPostLogin.razor (post-login component, gets user’s info, restores state) o PkceGenerator.cs (class that generates code_verifier and code_challenge, described in chapter 4) o SsoConnector.cs (a service that handles HTTP requests to a backend API for authentication, user’s info, token exchange, etc.) o SsoClientOptions.cs (model for client’s configuration) o TokenResponse.cs (model for the access_token response) o IBFFLightSignInManager.cs (interface for SignIn, SignOut, and GetClaimsPrincipalAsync methods) o BFFLightSignInManager.cs (implementation of the interface above, uses the
SsoConnector, PkceGenerator to handle sign in, sign out, and get user’s information) Extensions (folder with extension classes and methods) o IServiceCollectionExtensions.cs (provides an extension method AddBFFLightWasmAuth that configures options and injects required services during application start)
The second project is BFFLight.Server targets .NET Core 6.0 API and has necessary controllers, classes, and extensions for secure server authentication. The project structure is described below: Controllers (folder with API controllers) o SsoController.cs (main authentication controller with Token, GetProfile, and Logout methods; uses ISsoService implementation) Models (folder with models) o SsoServerOptions.cs (model for server’s configuration) o UserInfoModel.cs (model for user’s info) Services (folder with services) o ISsoService.cs (authentication service interface with methods GetAuthToken, GetProfile,
Logout) o SsoService.cs (default implementation of the ISsoService) Extensions (folder with extension classes and methods) o IServiceCollectionExtensions (provides an extension method AddBFFLightServerAuth that configures options and injects required services during application start) 7.2.
Before developers begin to use this library, they first need to make sure that their application is registered with an authentication provider. As a result of this registration process, they will get a Client ID and Client Secret. In addition, developer also needs to know the URL address of an OpenId SSO provider they use. The setup process begins with the installation of BFFLight.Wasm and BFFLight.Server to Blazor Web Assembly and .NET Core API projects respectively.
Let us review client’s configuration first. After installing NuGet packages, a developer should open Program.cs file in their Blazor project to add the following lines before the await builder.Build().RunAsync(): builder.Services.AddBFFLightWasmAuth(); // configure BFFLight services builder.Services.AddAuthorizationCore(); // add default Core authorization if not already added Next, a developer should open wwwroot/appsettings.json file (create a new file if it does not exist) and add the following configuration keys: “SsoClientOptions”: {
“ClientId”: “sso_provider_client_id”, // id given to you by the SSO provider after registration }
Finally, a developer should open the App.razor file and wrap all content in a <CascadingAuthenticationState></CascadingAuthenticationState> tag. This is a built-in Blazor tag used to propagate an authentication state down components’ tree. With the CasadingAuthenticationState, developers will be able to inject a [CascadingParameter] Task<AuthenticationState> parameter to then get the auth state and user’s information in their pages.
After completing client’s configuration, developers can move on to the server project setup. First, they should introduce a call to initialize BFFLight services in Program.cs file before the var app = builder.Build() line: builder.Services.AddBFFLightServerAuth(); // configure BFFLightServices
Moving on from the Program.cs setup, a developer should open appsettings.json file in order to add these configuration keys: “SsoServerOptions”: { “ClientId”: “sso_provider_client_id”, // id given to you by the SSO provider after registration “ClientSecret”: “sso_provider_secret”, // secret key provided by SSO after registration “SsoServiceUrl”: “sso_url”, // URL of the SSO provider }
This completes the configuration process. Following these steps and using our BFFLight library will allow developers to implement secure authentication and authorization in Blazor single page public client.
In this paper we have outlined key differences between confidential and public clients in terms of secure authorization, provided analysis of problems associated with secure authorization in public clients using OAUTH 2.0 protocol. During the analysis stage of this research, we have managed to discover algorithms, models, and methods for implementing secure authorization in public clients. In addition, we have performed practical modeling and implementation of Proof Key for Code Exchange algorithm with Backend For Frontend method. Finally, we have developed a proof-of-concept public client that uses our shared BFFLight library with the model and algorithm for secure authorization and is not vulnerable to attacks mentioned in the analysis phase: Cross-Site Scripting (XSS), Auth Code Interception, CSRF, etc.