andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

This in-depth guide shows you how to secure your AI chatbot built with .NET Blazor using the RAG pattern, ensuring users can only access information from documents they have permission to view.

Secure a .NET RAG System with Auth0 FGA

raphael-do-vale

Raphael has more than two decades of experience in developing enterprise systems including coding, project planning, architecture, and specification. His technology stack includes Java, Spring, Python, Relational Databases, JavaScript, DevOps, and Artificial Intelligence. He has a PhD and Master's degree in the Semantic Web, winning awards during his studies. He also worked with Description Logic, Prolog, RDF, and OWL tech.

Raphael do Vale

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

Understand the architectural patterns, testing strategies, and design principles required to turn a simple script into a scalable, production-ready FastAPI application.

FastAPI Best Practices

Learn how to keep tokens more secure by using the Backend for Frontend (BFF) architectural pattern.

One of the biggest challenges for applications using OAuth 2.0 and OpenID Connect is token security. Preventing an ID, access, or refresh token from falling into the wrong hands is a priority of these protocols. The specs have adopted several technical solutions, and some best practices have been proposed. Among the latter is the use of the Backend for Frontend pattern, whose rationale and architecture we will analyze in this article.

## OAuth 2.0 Client Types and Security

OAuth 2.0 defines two types of client applications: public and confidential clients. This classification is based on the application's ability to keep authentication credentials secure. From [the specs](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1):

- **Confidential**. Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.
- **Public**. Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

In a nutshell, confidential clients are those applications that run in a protected environment, such as a server, while public clients are applications that run in an uncontrolled environment, such as the user's device. Typical confidential clients are traditional web applications, while typical public clients are Single-Page Applications (SPA), desktop and mobile apps.

From a security perspective, public clients can't store their credentials securely. There is a high risk of tokens falling into the wrong hands. This can happen either because of a potential lack of protection on the local system or because of the potentially large number of instances of the application that increase the attack surface.

To mitigate the problem of issuing a token to a client that can't be authenticated (i.e., a public client), a specific flow has been designed: the [Authorization Code Flow with PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Anyway, this does not solve all the concerns about the security of a public client.

## SPA Security and Tokens

Another concern for public clients is token storage. Once an ID or access token is received from the server, how can a public client protect it from unauthorized access? As long as the application is running, the application memory is the safest place to store tokens. But what if the application stops running temporarily?

For example, consider a SPA that has a token in memory. What happens when the user refreshes the page on which the application is running? The token is lost, and the user is forced to authenticate again for the application to obtain a new token.

You could consider storing the token in the browser's local storage or in a cookie and reloading it after the refresh, but this is not a recommended practice. A malicious user or application could gain access to the local storage or cookie and obtain the token. See [this article for more information on the risks of using browser storage](https://auth0.com/blog/secure-browser-storage-the-facts/).

Something similar happens with native applications (desktop and mobile): when the user closes the application, all tokens are lost, requiring authentication the next time the application is opened. While this may be acceptable in certain contexts, many users have become accustomed to not having to authenticate every time they open their app, especially in the mobile environment. However, native applications have an advantage over SPAs. The presence of secure storage mechanisms in most popular operating systems, such as Keychain in iOS/Mac or Keystore in Android.

The level of security required by an application depends on its specific functionality. It is the result of balancing the data confidentiality requirements with the ease of implementation. Therefore, in some contexts, using the Authorization Code Flow with PKCE and all the concerns about token management in a SPA may be acceptable. In other contexts, it is not. What can you do for those contexts where you can't absolutely risk a token falling into the wrong hands?

## The Backend For Frontend Pattern

A seemingly marginal note in [the definition of client in the OAuth 2.0 specification](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) suggests a solution:

*A client may be implemented as **a distributed set of components, each with a different client type and security context** (e.g., a distributed client with both a confidential server-based component and a public browser-based component).*

This paves the way for the adoption of a well-known architectural pattern: the **Backend for Frontend** (BFF) pattern. This is a popular pattern to address specific needs for a client platform by building a dedicated backend. The needs may be of various types: decoupling of concerns, flexibility and maintainability, optimized performance, security, etc.

> Read [this document](https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html) to learn how this architectural pattern was born.

In our case, we are interested in strengthening the security of SPAs in the context of OIDC and OAuth 2.0, and the [best current practices](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-backend-for-frontend-bff) give us some guidelines about using this pattern.

Let's explore how the BFF pattern works.

### The BFF architecture

The actors involved in a typical scenario where a SPA uses the Authorization Code Flow with PKCE are shown in the following diagram:

![Architecture of a SPA using OIDC and OAuth2](https://images.ctfassets.net/23aumh6u8s0i/4PBIbTFxPR4PalUltQQEgV/69698b96960c0368e7429f6d1e3d8549/spa-oidc-oauth-architecture.png)

The SPA interacts with the authorization server to get the ID, access, and refresh tokens. Then, the SPA uses the ID token to get data about the user, the access token to call an API, and the refresh token to get a new access token once it expires.

In this scenario, all the tokens are in the hands of the SPA.

By applying the BFF pattern, we are going to enter a new component in this architecture, the dedicated backend, as shown below:

![BFF architecture](https://images.ctfassets.net/23aumh6u8s0i/43eXspNnMJS3ImbvAva0R9/5cf40b564dcbd03eb7394c15078d8b63/bff-architecture.png)

In this new scenario, the backend has three core responsibilities:

- It interacts with the authorization server as a confidential client.
- It manages all the tokens on behalf of the SPA, which can't access them anymore.
- It proxies all requests to the API, embedding the access token before forwarding them.

The SPA only interacts with the backend, relying on traditional cookies for authenticated sessions. Basically, the backend exposes a number of endpoints that let the SPA access the user profile data and the remote API.

This architecture improves the security of token negotiation, since it now happens via a confidential client, and token storage, since it now occurs on the server side.

### The BFF flow

Let's take a look at how the actors in this architecture interact with each other by following this diagram:

![Backend for Frontend flow](https://images.ctfassets.net/23aumh6u8s0i/6uM2x48XekNyFpODMiFjJq/c351e6278219b3865bd0bc6dd33e828b/backend-for-frontend-bff-flow.png)

Here are the descriptions for each step:

1. The SPA points to a backend URL (`/login` in the example above) to let the user authenticate.
2. The backend starts the usual OpenID Connect negotiation with the authorization server: it redirects the user browser to the authorization endpoint to authenticate the user and get the needed tokens.
3. The authorization server issues the tokens to the backend, which can store it in a cache.
4. The backend issues a cookie representing the user session and triggers the reloading of the SPA in the browser.
5. The SPA makes an API request to the backend including the cookie.
6. The backend validates the SPA request, retrieves the associated access token, and uses the token to make a call to the API.
7. The API returns a response to the backend.
8. The backend forwards the response to the SPA.

## Caveats and Variations

The BFF pattern solves the main concerns about using SPAs in an OIDC/OAuth 2.0 flow:

- There is no longer a public client negotiating the tokens, but this negotiation is now the responsibility of a confidential client represented by the backend.
- The SPA no longer needs to store tokens to prevent user re-authentication after page refresh.

To properly implement the BFF, there are a few caveats you need to pay attention to:

- The session cookie issued by the backend must be marked `Secure` and `HttpOnly`.
- The cookie must be associated with the token(s) issued by the authorization server.
- The tokens can be stored on the server side or in the session cookie. In the latter case, the cookie must be encrypted.
- The backend must implement all the measures to prevent Cross-Site Request Forgery (CSRF) attacks.
- The BFF pattern does not work for a standalone SPA that relies on calling a protected API directly from JavaScript. The SPA must be hosted by the backend, which is implemented as a regular web application.

While the BFF pattern solves the main security concerns of token exchange and storage for SPAs, some developers are concerned about performance issues. Specifically, the mediation run by the backend as a proxy API can be a bottleneck in some contexts. There is an alternative to the BFF pattern that meets this need, but it comes at the cost of reduced security.

This alternative is the [Token-Mediating Backend pattern](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-token-mediating-backend), which allows the backend to negotiate the tokens as in the BFF pattern but provides the access token to the SPA. This way, the SPA can directly call the protected API using the access token. While this pattern keeps token negotiation secure by always relying on the backend as a confidential client, it leaves the issue of storing and protecting the access token open. To overcome this issue, you can consider [using OAuth 2.0 with DPoP](https://auth0.com/blog/oauth2-security-enhancements/#Demonstrating-Proof-of-Possession--DPoP), which binds an access token to the client, making it no longer a bearer token. In this case, you need a DPoP-enabled authorization server, of course.

## Summary

Now you have a better understanding of the concerns related to token management and SPAs. You learned that SPAs, like any public client, are not always a safe place to handle ID, access, and refresh tokens. Much depends on the specific business requirements of the application, of course.

If you need a more secure architecture for your SPA, you can apply the Backend for Frontend pattern. This pattern introduces a dedicated backend for token negotiation and management on behalf of the SPA. This way, no tokens will reach the SPA, while the backend will also take charge of proxying the requests to a protected API.

The Backend for Frontend Pattern

pablo-cibraro

Pablo is an internationally recognized expert and entrepreneur with more than 22 years of experience in designing and implementing large distributed systems with Microsoft technologies and a Connected System MVP. 
For the last few years, Pablo has helped numerous Microsoft teams develop tools and frameworks for building service-oriented and web applications with .NET. 
Pablo now focuses on technologies that enable developers to build large-scale systems and web applications on the cloud, such as HTML5, Node.js, ASP.NET, Windows Azure and Amazon AWS.

Agilesight Cofounder

Pablo Cibraro

Understand the Backend For Frontend authentication pattern and how it can be implemented in ASP.NET with Auth0.

Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core

giridhar

I love programming, learning and building new things.  I can develop web applications using Javascript and software applications using Python. 

Creative Web Developer

Giridhar Talla

Learn to implement state pattern and finite state machines using Python.

[Design patterns](https://en.wikipedia.org/wiki/Software_design_pattern) are conventional solutions to common challenges in software development using [Object-oriented programming](https://en.wikipedia.org/wiki/Object-oriented_programming). One of the famous design patterns for developing scalable and flexible software is the state pattern. You'll learn about the state pattern and how to apply it to improve your software project in this article.

## Finite State Machine

Let's define a [finite state machine](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) before moving on to the state design pattern. It is well known that the concepts of state patterns and finite-state machines have a close relationship. An FSM is something that behaves differently depending on its internal state. In computer programming, the behavior of an object in an application varies depending on its state. A switch and a lightbulb are simple examples of FSM. "ON" and "OFF" are the two possible states of the light bulb. To change the state of the bulb 'ON' or 'OFF', simply flip the switch. Transition is the process of moving from one state to another. Transition is affected by several factors. In the case of the light bulb, it is dependent on the input from the switch. The state diagram, which is shown below, graphically depicts the states and transitions.

![light bulb state diagram](https://images.ctfassets.net/23aumh6u8s0i/6Y4Ljm8KBa45GF54np9a8i/b5bff5c1cf9b5a8ead644a110f9db059/01_bulb_state_diagram.png)

We can implement the state machine using any programming language. Depending on a few factors, our code behaves differently. You can implement the preceding light bulb example as follows:

```py
class LightBulb:
  _state = 'OFF'    # initial state of bulb
  
  def onOff(self, switch):
    if switch == 'ON':
        self._state = 'ON'
    elif switch == 'OFF':
        self._state = 'OFF'
    else:
        continue          # if we get wrong input

```

For small systems, such as the one described above, the code appears to be straightforward and simple. However, if there are many states and transitions, our code will get flabby with conditional statements. The code becomes more extensive, and it won't be easy to maintain the application. If you want to add additional states or transitions to the program, you'll have to change the entire code base. You can use the **State Design Pattern** in these cases.

## State Pattern

It is a behavioral design pattern. You can use the state pattern to implement state-specific behavior in which objects can change their functionality at runtime. You can use it to avoid using conditional statements when changing an object's behavior based on its state. In the state pattern, you should [encapsulate](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) different states in separate `State` classes. The original class keeps a reference to a state object based on its current state rather than using conditional statements to implement state-dependent functionality.

## UML Diagram

![UML class diagram of state pattern](https://images.ctfassets.net/23aumh6u8s0i/7EXrJIISe60aDo65BUFXgW/caabc74e7fe1d13bc1150ce6baa98edb/02_UML_state_class.png)

1) **Context** - it is the original class of our application. It maintains a reference to one of the concrete states on which its behavior depends. It also has a method to modify the internal state.

2) **State interface** - All supported states share the same state interface. Only the state interface allows *Context* to communicate with state objects. *Context* can only communicate with state objects via the state interface.

3) **Concrete states** - For each state, these objects implement the 'State' interface. These are the main objects which contain the state-specific methods.

## How does it work?

![UML sequence diagram of state pattern](https://images.ctfassets.net/23aumh6u8s0i/9jQ2UH5r4b4amneAHwIxG/fa3b9affd7c467bc6513b64cd1362114/03_UML_state_sequence.png)

Assume the *Context* is configured with an initial state, `concreteStateA`.  It behaves according to its initial state. The *Context* now implements the `doSomething` method according to `concreteStateA`. The concrete states should contain a back reference to call back and change *Context's* current state object. If a state transition occurs, the *Context's* `setSate` method is invoked, referencing the new state, `concreteStateB`. The *Context* changed its internal state and behavior. Now, it uses the `concreteStateB` to implement the `doSomething` method. The basic idea is that the states can change the context's state automatically. As a developer, you can modify the states by using any number of instances of `setState`.

If you want to add another state, simply create a new concrete state object without changing the *Context* of the application.

## Implementation

Let's take a step-by-step look at implementing the state pattern.

1) Find an existing class that contains state-dependent code, or create a suitable context class. It should include a reference to a specific state as well as a method for switching between states.

```py
from __future__ import annotations
from abc import ABC, abstractmethod

# the context class contains a _state that references the concrete state and setState method to change between states.
class Context:

    _state = None

    def __init__(self, state: State) -> None:
        self.setState(state)

    def setState(self, state: State):

        print(f"Context: Transitioning to {type(state).__name__}")
        self._state = state
        self._state.context = self

    def doSomething(self):
        self._state.doSomething()

```

2) Create a common State interface for all concrete states. The State interface specifies all of the methods that all Concrete States must implement and a backreference to the *Context* object. States can change the *Context* to another state by using this backreference.

```py
class State(ABC):
    @property
    def context(self) -> Context:
        return self._context

    @context.setter
    def context(self, context: Context) -> None:
        self._context = context

    @abstractmethod
    def doSomething(self) -> None:
        pass

```

You should define the *Context* as a [protected parameter](https://www.geeksforgeeks.org/protected-variable-in-python/). Above, [`@property`](https://www.programiz.com/python-programming/property) decorator is used to make the `context()` method as property and `@context.setter` decorator to another overload of the `context()` method as property setter method. Now, `_context` is protected.

3) You can define the concrete states in the classes that implement the state interface. After the `doSomething` method is called, the state of the *Context* changes. You can also change the state by defining a specific method. The state transitions use the `setState` method of the *Context*.

```py
class ConcreteStateA(State):
    def doSomething(self) -> None:
        print("The context is in the state of ConcreteStateA.")
        print("ConcreteStateA now changes the state of the context.")
        self.context.setState(ConcreteStateB())


class ConcreteStateB(State):
    def doSomething(self) -> None:
        print("The context is in the state of ConcreteStateB.")
        print("ConcreteStateB wants to change the state of the context.")
        self.context.setState(ConcreteStateA()) 

```

4) You can now initiate your application with an initial state and execute the methods.

```py
# sample application
app = Context(ConcreteStateA())
app.doSomething()    # this method is executed as in state 1
app.doSomething()    # this method is executed as in state 2
```

The output of the above code looks something like this:

```
Context: Transitioning to ConcreteStateA
The context is in the state of ConcreteStateA.
ConcreteStateA now changes the state of the context.
Context: Transitioning to ConcreteStateB
The context is in the state of ConcreteStateB.
ConcreteStateB wants to change the state of the context.
Context: Transitioning to ConcreteStateA
```

## Example

Let's create a simple state machine that represents a real-world scenario. Consider an elevator system with buttons in the elevator cabin that allow you to go up or down. Consider that this lift only travels between two floors to keep things simple. There are primarily two possible states for the elevator: `1st floor` and `2nd floor`. The input from the two buttons determines the transition between states. The elevator performs different actions based on its state.

The following code is the implementation of the elevator example. Follow along with the comments for more descriptions about each method.

```py
from __future__ import annotations
from abc import ABC, abstractmethod

# The Elevator class is the context. It should be initiated with a default state.
class Elevator:

    _state = None

    def __init__(self, state: State) -> None:
        self.setElevator(state)

    # method to change the state of the object
    def setElevator(self, state: State):

        self._state = state
        self._state.elevator = self

    def presentState(self):
        print(f"Elevator is in {type(self._state).__name__}")

    # the methods for executing the elevator functionality. These depends on the current state of the object.
    def pushDownBtn(self):
        self._state.pushDownBtn()

    def pushUpBtn(self):
        self._state.pushUpBtn()

    # if both the buttons are pushed at a time, nothing should happen
    def pushUpAndDownBtns(self) -> None:
        print("Oops.. you should press one button at a time")

    # if no button was pushed, it should just wait open for guests
    def noBtnPushed(self) -> None:
        print("Press any button. Up or Down")


# The common state interface for all the states
class State(ABC):
    @property
    def elevator(self) -> Elevator:
        return self._elevator

    @elevator.setter
    def elevator(self, elevator: Elevator) -> None:
        self._elevator = elevator

    @abstractmethod
    def pushDownBtn(self) -> None:
        pass

    @abstractmethod
    def pushUpBtn(self) -> None:
        pass


# The concrete states
# We have two states of the elevator: when it is on the First floor and the Second floor
class firstFloor(State):

    # If the down button is pushed when it is already on the first floor, nothing should happen
    def pushDownBtn(self) -> None:
        print("Already in the bottom floor")

    # if up button is pushed, move upwards then it changes its state to second floor.
    def pushUpBtn(self) -> None:
        print("Elevator moving upward one floor.")
        self.elevator.setElevator(secondFloor())


class secondFloor(State):

    # if down button is pushed it should move one floor down and open the door
    def pushDownBtn(self) -> None:
        print("Elevator moving down a floor...")
        self.elevator.setElevator(firstFloor())

    # if up button is pushed nothing should happen
    def pushUpBtn(self) -> None:
        print("Already in the top floor")


if __name__ == "__main__":
    # The client code.

    myElevator = Elevator(firstFloor())
    myElevator.presentState()

    # Up button is pushed
    myElevator.pushUpBtn()

    myElevator.presentState()

```

The output of the above code looks like this:

```
Elevator is in firstFloor
Elevator moving upward one floor.
Elevator is in secondFloor
```
You can implement many buttons and states elevator like in real-life one for the floor. Try using the state pattern to implement the light bulb example from the Finite state machine.

## Advantages and Disadvantages

The state pattern, like any other programming concept, has a number of benefits as well as some drawbacks. You can avoid writing massive conditional blocks for switching between states by using the state pattern instead of hard-coding state-specific behavior. It allows you to develop a flexible and maintainable application. You can add new states and transitions to the *Context* without changing it.

It's a good idea to use the state pattern if the logic of each state is complex and the states change frequently. Otherwise, it complicates simple things by bringing a plethora of classes and objects. The state pattern adds another level of indirection by imposing clients to rely on a State object, and it extends the context class to allow State objects to change the state of the *Context*.

## Conclusion

In this article, you learned how to use the state pattern in Python programming to design state machines. Without using larger conditional blocks to implement state-specific behavior, the state pattern makes the development process a lot easier. You can also add new states that are not dependent on other states, giving your application more flexibility. The state pattern is very similar to the [strategy pattern](https://en.wikipedia.org/wiki/Strategy_pattern), which alters strategies based on user choices. The main distinction is that concrete states are aware of other states, whereas the strategies do not. Why do we say that states are aware of other states? because each state has to know to which state they should move. For example, the first-floor state knows that they should change to the second-floor state. Another important difference with strategy pattern is that in the case of Strategy pattern, it's the client, which provides a different strategy to Context, on State pattern, the state transition is managed by Context or State itself. Try to make use of the state pattern in your software to make the development process go more smoothly.

State Pattern in Python

Learn strategy design pattern to write better code in Python

While you are developing software applications, you might run into some problems implementing the feature you need. Software design patterns are typical solutions for some of these commonly occurring problems while developing software applications using Object-oriented design. In this article, let's learn about one of the popular design patterns, **Strategy** pattern, and its implementation in Python.

## Introduction

Before diving into the strategy pattern, you should be familiar with some of the basics concepts of [Object-Oriented Programming](https://en.wikipedia.org/wiki/Object-oriented_programming) (OOP). The entire concept of design patterns revolves around *classes* and *objects*. The design patterns are more high-level solutions for commonly occurring problems. They are like the blueprint to solve a specific problem. They are not confined to a single programming language. You can use design patterns in any programming language that supports object-oriented programming; the process will be the same while the syntax changes.
![design patterns](https://images.ctfassets.net/23aumh6u8s0i/4tPzU9nvm5jUwrXAeeHH3e/1badc171178aa953f7df05f08960f228/01_design-types.jpg)
There are several types of design patterns, including **Creational**, **Structural**, and **Behavioral** patterns. Creational patterns are about different ways to create objects that increase the flexibility of our code. Structural patterns are about relations between the objects, making larger structures flexible using objects and classes. Behavioral patterns are about effective communications and interactions between objects.

## Strategy

**Strategy Pattern** is a design pattern that enables our application to select algorithms at runtime, making our application flexible. The original book on [design patterns](https://en.wikipedia.org/wiki/Design_Patterns) written by [GoF](http://wiki.c2.com/?GangOfFour) states that "Strategy pattern intends to define a family of algorithms, encapsulates each one, and
make them interchangeable." More specifically, it lets you define a set of algorithms that are interchangeable according to some factors at runtime. Strategy Pattern falls under the category of behavioral design patterns as it enables an algorithm's behavior to be selected at runtime.

## Usage

While developing software applications, you may have a few alternatives to accomplish something in your code. Depending on your client choices, data sources, or other factors, you want to do something different without changing the code. You often tend to define algorithms using conditional statements for different situations in the main class of the code. But it is not an elegant way of writing better code. It makes the main class of your code quite long, and it becomes too hard to maintain the application.

In situations like these, the strategy pattern is an ideal solution. The strategy pattern suggests you define classes, called *strategies*, for your algorithms of different situations. The strategy is referenced inside the main class, called _context_, and the code works according to that situation. The context does not select an appropriate strategy for the case. Instead, the client passes the desired strategy to the context.

For example, if you have a chess application, you can select the difficulty level between easy, medium, or hard. The computer chooses an algorithm according to the level you choose. It is one of the best examples where the strategy pattern is used.

Strategy pattern follows the [Open/close principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle); a software application is open for extension but closed for modification. It means you can add any number of additional strategies without modifying the main class. It makes your code more flexible and easy to maintain.

## UML Diagrams

The following is the UML diagram of the Strategy pattern.

![UML Strategy](https://images.ctfassets.net/23aumh6u8s0i/21fvYspoS3Voqv7pKyDE4E/e89c3e5f81d51b3d15a436cd81e795f7/02_UML-Strategy.jpg)

1. **Context** &mdash; It is the primary class of our application. It maintains a reference to one of the concrete strategies.
2. **Strategy** &mdash; Strategy interface is common to all supported strategies. Context can communicate with other strategies only through the strategy interface.
3. **ConcreteStrategies** &mdash; These are the classes that implement the algorithm using the Strategy interface.

## Implementation

Let's see the step-by-step process of implementing a strategy pattern.

1. You should first identify algorithms you want to execute as concrete strategies in the primary class.
2. Define the *context* (primary class) and add a reference to the strategy, a method to set the strategy, and another method to execute the strategy. You may also define a default strategy to switch between strategies only if they do not like the default one.

```py
## context - the primary class
class Context:
    strategy: Strategy  ## the strategy interface

    def setStrategy(self, strategy: Strategy = None) -> None:
        if strategy is not None:
            self.strategy = strategy
        else:
            self.strategy = Default()

    def executeStrategy(self) -> str:
        print(self.strategy.execute())

```

First, we define the `strategy` field for storing a reference to a strategy object, and two methods, `setStrategy` and `executeStrategy`. The `setStrategy` sets the strategy selected if a user selects an option, or else the `default` one.

3. Define the *Strategy Interface*, which is common to all the concrete strategies. The `Strategy` interface has an abstract method that you can alter in concrete strategies. 

```py
from abc import ABC, abstractmethod

## Strategy interface
class Strategy(ABC):
    @abstractmethod
    def execute(self) -> str:
        pass
```

4. Define the concrete strategies which should implement the `Strategy` interface. These concrete strategies must have a common method that overrides the `execute` method of the `Strategy` interface.

```py
## Concrete strategies
class ConcreteStrategyA(Strategy):
    def execute(self) -> str:
        return "ConcreteStrategy A"

class ConcreteStrategyB(Strategy):
    def execute(self) -> str:
        return "ConcreteStrategy B"

class Default(Strategy):
    def execute(self) -> str:
        return "Default"
```

5. Now, users can select the strategy they want at the runtime. Create an object of *context* and pass a concrete strategy.

```py
## Example application
appA = Context()
appB = Context()
appC = Context()

## selecting stratigies
appA.setStrategy(ConcreteStrategyA())
appB.setStrategy(ConcreteStrategyB())
appC.setStrategy()    ## sets to default strategy

## each object below execute different strategy with same method
appA.executeStrategy()
appB.executeStrategy()
appC.executeStrategy()
```

The output of the above code will be as follow:

```
ConcreteStrategy A
ConcreteStrategy B
Default
```

If you want to use another strategy, replace the ConcreteStrategy instance with the strategy you want. You can add a new concrete strategy without changing anything in the context.

## Example

Let's design a [rock paper scissors](https://en.wikipedia.org/wiki/Rock_paper_scissors) game using strategy pattern. You can select any strategy among rock, paper, scissors, and random to play against the computer. The below example code uses the strategy pattern to implement various strategies.

```py
## Changing the strategy among Rock, Paper, Scissors, and Random

import random
from abc import ABC, abstractmethod

## Strategy interface 
class Strategy(ABC):
    @abstractmethod
    def selection(self) -> None:
        pass

## Concrete strategies
class Rock(Strategy):
    ## actual application will have the algorithm instead this method
    def selection(self) -> str:
        return "Rock"

class Paper(Strategy):
    def selection(self) -> str:
        return "Paper"

class Scissors(Strategy):
    def selection(self) -> str:
        return "Scissors"

class Random(Strategy):
    def selection(self) -> str:
        options = ["Rock", "Paper", "Scissors"]
        return random.choice(options)

## Context class
class Game:
    strategy: Strategy

    def __init__(self, strategy: Strategy = None) -> None:
        if strategy is not None:
            self.strategy = strategy
        else:
            self.strategy = Random()

    def play(self, sec) -> None:
        s1 = self.strategy.selection()
        s2 = sec.strategy.selection()
        if s1 == s2:
            print("It's a tie")
        elif s1 == "Rock":
            if s2 == "Scissors":
                print("Player 1 wins!")
            else:
                print("Player 2 wins!")
        elif s1 == "Scissors":
            if s2 == "Paper":
                print("Player 1 wins!")
            else:
                print("Player 2 wins!")
        elif s1 == "Paper":
            if s2 == "Rock":
                print("Player 1 wins!")
            else:
                print("Player 2 wins!")

## Example application
## PLayer 1 can select his strategy
player1 = Game(Paper())

# Player 2 gets to select
player2 = Game(Rock())

# After the second player choice, we call the play method
player1.play(player2)
```

According to the strategies chosen by the two players, the expected output would be:

```bash
Player 1 wins!
```

Test all the other cases of the game using all the other strategies. To add extra fun to the game, try creating two more strategies to the above example according to [the Lizard-Spock expansion](https://bigbangtheory.fandom.com/wiki/Rock,_Paper,_Scissors,_Lizard,_Spock).

## Conclusion

In this article, you have seen where and how to use the strategy pattern in your code. You can build flexible and maintainable software applications using the strategy pattern. You can switch between algorithms at runtime according to the user's decision without changing the code. But if your code only has a couple of algorithms, there is no need to use strategy. It just makes your code look complex with numerous classes and objects. The Strategy pattern can work as an alternative for conditional statements for selecting the behavior of the application. But the potential drawback of strategy pattern is that the users must know how strategies differ from each other to select what they need. So it would be best if you use the strategy pattern only when the variation in behavior of the application is relevant to the users. So try to make your software applications flexible using the strategy pattern.

Strategy Design Pattern in Python

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

New survey reveals behaviors and usage patterns of application builders; authentication required in 83% of applications built

**BELLEVUE, Wash. – May 19, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today released a [**2020 State of Application Assembly**](https://auth0.com/resources/whitepapers/state-app-assembly-2020) survey, revealing that a majority of development teams are turning to best-in-class SaaS services and the adaptability of APIs for building unique features and functionalities into the many apps they are responsible for each year.

Surveying 426 global technical professionals across a variety of roles (developers, engineers, CTOs, directors of engineering, software architects) and company sizes, Auth0 determined that 51% of respondents are responsible for building two to five apps per year, and more than a quarter (28%) build 6-10+ apps per year, with three-quarters of these apps being used for external audiences. There are currently more than 4.1 million apps available on leading app stores ([Statista](https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/)), indicating the staggering amount of development these builders are responsible for. 

The survey explored application builder behavior around several services and key findings included: 

* For applications that required payment, 74% of respondents outsourced, with Stripe being the dominant tool of choice.
* For applications that required messaging, 71% outsourced this solution, with Twilio being the highly preferred tool.
* The third service explored was authentication, cited as a requirement in 83% of applications built. However, the numbers for outsourcing authentication were lower than the other two services, with respondents outsourcing 58% of the time. 

With a substantial percentage of companies still building authentication tools in-house – and because authentication is present in the majority of apps – there’s a large potential opportunity for application building teams to streamline their processes and improve efficiency by using a third-party IDaaS tool. 

The accelerated timelines that come with app launches are driving teams away from in-house development and towards microservices – app ‘building blocks’ – that provide features and functionality that would be nearly impossible to build and maintain themselves. Relying on third-party services that are adaptable to their specific needs, significantly frees the team’s resources to focus on core innovation and speed-to-market. 

“These results confirm a trend of application development teams increasingly relying on first- and third-party APIs and external SaaS services when assembling apps, to simultaneously decrease time-to-market and increase completeness and security,” said Martin Gontovnikas, SVP of Marketing and Growth at Auth0. “Whether it’s payments, messaging, or authentication, this survey shows that teams are turning more to a ‘must-have SaaS stack’ to expedite development and enable them to focus on their core product.” 

The move to outsource services that are proven and fully adaptable gives application teams a competitive edge in innovation and implementation. By 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code. Combined with agile/DevOps approaches and methodologies, enterprises can dramatically accelerate their ability to push out digital innovation – at 50-100x (or more) the frequency of traditional approaches ([IDC](https://www.idc.com/getdoc.jsp?containerId=prUS44417618)).

Please visit the [State of Application Assembly](https://auth0.com/resources/whitepapers/state-app-assembly-2020) for further details and to view all survey results.


<include src="asides/AboutAuth0" />

### Media Contacts
Jeana Tahnk 
Auth0 Global Communications 
[press@auth0.com](mailto:press@auth0.com)

Hannah Carroll 
Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Majority of Application Development Teams Rely More On SaaS Services vs. Building In-House

sambiopic

I'm Director of Developer Relations and a Google Developer Expert for Angular and Web Technologies. I believe anyone who wants to learn to code should be able to learn code and I love teaching. When I'm not coding or writing, you'll find me outside hiking or camping in the beautiful Pacific Northwest.

Director of Developer Relations

Sam Julien

Learn about the facade pattern, why you may or may not want to use one with NgRx, and how to create a facade.

"pattern"