Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Production-ready AI agents need to be secure, and auth is a big part of security. Auth0 is partnering with Google Cloud to help deliver secure authentication for the Agent2Agent (A2A) protocol.

## What Is the Agent2Agent Protocol?

[Agent2Agent (or A2A)](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) is a new open interoperability protocol created by Google Cloud, and launched a month ago,  with support and contributions from 60+ companies.

It aims to allow agents to communicate with other agents regardless of their implementation framework or tech stack. For example, a “client” agent should be able to communicate with server agents implemented with LangGraph, Google ADK, Vercel AI SDK, any other agentic framework, or any agent implemented without one.

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/RYuhvCQkWJzgSl1ZoZGqj/62881d062e978f8d733ed58ad743e3bf/01_Agent2Agent_protocol.png)

## Why Is Auth Important for AI Agents?

As companies and developers deploy AI agents into production, interactions between these agents will be common. And naturally, these interactions need to be secure.

We can say that each AI agent can act as a client (when requesting data from other AI agents) and as a server (when responding to data requests from other AI agents).

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/54RtL5WuaBcv9Tu1He2ngO/4131696834c22e88ec061edad4d07dab/02_Agent2Agent_protocol.png)

So we ended up with some auth-related questions that needed to be answered. These matters are important when implementing any system, and agentic systems are no exception. But there are also a few questions that become more prevalent with the rise of AI agents:

* **Authentication:** How does the server agent know who is trying to perform an action?
* **Delegation:** Is the agent acting on its behalf, or on behalf of a user?
* **Consent:** If the client is acting on behalf of a user, how does the user consent to this operation?
* **Authorization:** How does the server agent know if the caller can perform the action (e.g., call a specific tool)? If the client is acting on behalf of a user, is the user authorized to perform this action?
* **Auth for headless agents (agents without a UI):** How should AI agents without a UI authenticate users?
* **Fine-grained authorization:** How do we ensure AI agents only have the permissions they need to perform their task, and not more?

## What Are We Partnering On?

A2A is being designed to support enterprise-grade authentication and authorization from day one. This means the protocol should be able to provide good answers to those questions and support all of those scenarios in multi-agent systems built with A2A.

We are working with Google Cloud to define A2A auth specs based on secure standards and build SDKs and code samples that showcase A2A auth capabilities. This will include how to integrate A2A with [Auth0](https://auth0.com/) and our new product [Auth for GenAI](https://auth0.com/ai), providing both great security and great auth user experiences.

## How Does Auth Work in A2A?

Agents expose how they operate via [Agent Cards](https://google.github.io/A2A/topics/key-concepts/#fundamental-communication-elements), which include what they can do, how they can communicate (e.g. support streaming?), and how clients should authenticate to them following the [OpenAPI spec](https://github.com/google/A2A/pull/359). Clients use the Agent Card to discover agents and understand how to interact with them.

For example, this agent card defines an HR agent as someone who can receive an email and reply if a person works at a company or not. Clients can authenticate by obtaining an access token via a [client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) OAuth flow and then providing the token to the agent to authenticate.


```py
AgentCard(
    name='Staff0 HR Agent',
    description='This agent handles external verification requests about Staff0 employees made by third parties.',
    url=f'http://{host}:{port}/',
    version='1.0.0',
    defaultInputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    defaultOutputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    capabilities=AgentCapabilities(streaming=True),
    skills=[
        AgentSkill(
            id='is_active_employee',
            name='Check Employment Status Tool',
            description='Confirm whether a person is an active employee of the company.',
            tags=['employment status'],
            examples=[
                'Does John Doe with email jdoe@staff0.com work at Staff0?'
            ],
        )
    ],
    securitySchemes={
        'oauth2_m2m_client': OAuth2SecurityScheme(
            description='',
            flows=OAuthFlows(
                authorizationCode=ClientCredentialsOAuthFlow(
                    tokenUrl=f'https://{os.getenv("HR_AUTH0_DOMAIN")}/oauth/token',
                    scopes={
                        'read:employee_status': 'Allows confirming whether a person is an active employee of the company.',
                    },
                ),
            ),
        ),
    },
    security=[{
        'oauth2_m2m_client': [
            'read:employee_status',
        ],
    }],
)
```

One thing we have also been exploring with the Google Cloud team is how agents that don't have a UI (“headless agents”) should authenticate users. For these scenarios, we believe the [Client Initiated Backchannel Authentication](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) (CIBA) flow will be a very valuable tool for developers and architects. CIBA is an OpenID Connect flow that does not rely on redirects in the user's browser. Instead, Agents can reach out to users outside via push notification, email, SMS, etc., for them to authenticate. To give you an idea about what CIBA provides from a security standpoint, it can also be used to meet the strong auth requirements of [FAPI](https://openid.net/wg/fapi/) for financial transactions.

## A Working Sample

Enough chat, let's see some working code :) We've worked with the Google Cloud A2A team to build a demo showcasing these capabilities. Imagine a scenario where:

1. John Doe, who works at Staff0, wants to open a bank account by talking to a chatbot agent
2. Because of internal policies, the bank agent needs to verify that the user is an employee at Staff0, so it contacts the Staff0 HR agent.
3. The Staff0 HR agent can use the Staff0 HR API to check if the user is an employee or not.

For example, it could result in an application flow like this:

<iframe class="vidyard_iframe" title="Auth0 + Google A2A & ADK sample" src="//play.vidyard.com/utu4caQfTCBHbbnXDaWo9a.html?" width="640" height="360" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen referrerpolicy="no-referrer-when-downgrade"></iframe>

To make it simple to run such a sample, we uploaded it to the A2A repo [here](https://github.com/google/A2A/tree/main/samples/python/agents/headless_agent_auth). The sample A2A client plays the part of the Bank Agent. When you run the demo, this is what happens behind the scenes:

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/4NIuz6gLOicE7kPjRnqvuG/25b9a819ef795458117927f488235919/03_Agent2Agent_protocol.png)

## Closing Thoughts

At Auth0 we believe AI has the potential to radically reshape software in general and identity in particular. We believe there will be an explosion in AI agents (non-human identities), which requires more security, finer grained access control and support for various delegation scenarios. 

We look forward to continuing our collaboration with Google Cloud, and helping builders secure their AI agents, both by contributing to AI protocols (e.g. MCP, A2A), new capabilities of [Auth for GenAI](https://auth0.ai/), and developing new products and features that enable an AI powered world.


Secure A2A Authentication with Auth0 and Google Cloud

shahid-mansuri

Guest Author

Shahid Mansuri

Out of the box, Laravel ships with many features that make your applications ready for prime time. In this article, you will learn about these features.

**TL;DR:** Laravel makes your applications more secure by default, which makes it the recommended PHP framework for mission-critical applications. In this article, we will briefly address how Laravel can help you create mission-critical, production-ready applications.

## Introduction

For a mission-critical application, there are two levels of security that matters: application security and server security. [Laravel](https://laravel.com/) is a development framework and, as such, it won't make your server more secure, just your application.

Laravel features allow you to use everything securely. All the data is sanitized where needed unless you're using Laravel with raw queries. Then, you're on your own basically. The point is, Laravel gives you security for common vulnerabilities.

So, in this article, you will learn about the most important security features of Laravel.

<include src="TweetQuote" quoteText="Learn why Laravel is the best PHP framework for mission-critical, production-ready applications."/>

## Protecting Laravel Applications from SQL Injection

Laravel protects you from [SQL injection](https://www.w3schools.com/sql/sql_injection.asp) as long as you're using the [Fluent Query Builder](https://laravel.com/docs/5.6/queries) or [Eloquent](https://laravel.com/docs/5.6/eloquent).

Laravel does this by making prepared statements which are going to escape any user input that may come in through your forms. If hackers add a new input to a form, they may try to insert a quote and then run their own custom SQL query to damage or read your application database. However, this won't work since you are using Eloquent. Eloquent is going to escape this SQL command and the invalid query will just be saved as text into the database.

The take away is: if you're using the Fluent Query Builder or Eloquent, your application is safe from SQL injections.

> [To learn more about SQL injection protection on Laravel check out this article](https://www.easylaravelbook.com/blog/how-laravel-5-prevents-sql-injection-cross-site-request-forgery-and-cross-site-scripting/).

## Protecting Cookies on Laravel Applications

Laravel will also protect your cookies. For that, you will need to [generate a new Application Key](http://laravel-recipes.com/recipes/283/generating-a-new-application-key). If it’s a new project, use the PHP artisan `key:generate` command.

For existing projects running on Laravel 3, you will need to switch to a text editor, then go to your application's `config` directory and open the `application.php` file. There, you will find the key under the _Application Key_ section.

On Laravel 5 and above, _Application Key_ is called _Encryption Key_. You can find this key in the `app.php` file that resides in the `config` folder.

The Application Key or Encryption Key uses encryption and cookie classes to generate secure encrypted strings and hashes. It is extremely important that this key remains secret and should not be shared with anyone. Also, make it about 32 characters of random gibberish so that nobody can guess it as Laravel uses this key to validate the cookie.

As mentioned above, Laravel auto-generates the Application Key; however, if required, you can edit it from the `application.php` file.

The cookie class uses the Application key to generate secure encrypted strings and hashes. Laravel will protect your cookies by using a hash and making sure that no one tampers with them.

## Cross-Site Request Forgery (CSRF) Protection on Laravel

To protect your application from a <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)">CSRF attack</a>, Laravel uses the Form Classes Token method, which creates a unique token in a form. So, if you look at the source code of a target form, you will see a hidden form field called CSRF token.

``` html  

<form name="test">
{!! csrf_field() !!}

</form>

```


The token makes sure that the request is coming from your application and not from somewhere else. With that token, you need to make sure that it's checking for a forged request. Laravel has CSRF-protection enabled by default.

Laravel adds a pre-defined CSRF filter in your app that looks like this:

```php
<?php
Route::filter('csrf', function() {
   if (Session::token() != Input::get('_token')) {
       throw new Illuminate\Session\TokenMismatchException;
   }
});
```

The CSRF filter allows you to check for a forged request and if it has been forged, it's going to return an HTTP 500 error. You can use the Form Classes Token method and CSRF filter together to protect your application routes.

## Mass Assignment Vulnerabilities on Laravel

[Object-relational mapping tools](https://en.wikipedia.org/wiki/Object-relational_mapping) (like Eloquent) have the ability to mass-assign properties directly into the database, which is a security vulnerability.

For those who don’t know, Laravel’s ORM (Eloquent) offer a simple Active-Record implementation for working with your database. Each database table has a corresponding `Model_Class` that interacts with that table.

Mass assignment let you set a bunch of fields on the model in a single go, rather than sequentially, something like:

```php
$user = new User(Input::all());
```

> The command above sets all value at the same time, in one go.

For example, your application can have a user table and with a user_type field. This field can have values of: `user` or `admin`.

In this case, you don’t want your users to update this field manually. However, the above code could allow someone to inject a new `user_type` field. After that, they can switch their account to `admin`.

By adding to the code:

```php
$fillable = array('name', 'password', 'email');
```

You make sure only the above values are updatable with mass assignment.

To be able to update the `user_type` value, you need to explicitly set it on the model and save it, as shown here:

```php
$user->user_type = 'admin';
$user->save();
```

## Cross-Site Scripting Protection on Laravel

Laravel's `@{{}}` syntax will escape any HTML objects that are the part of a view variable. It’s a big-deal, considering that a malevolent user can authorize the subsequent string into a comment or user profile:

``` html  

My list <script>alert("spam spam spam!")</script>

```

![Avoiding cross-site scripting attacks on Laravel applications.](https://images.ctfassets.net/23aumh6u8s0i/5WdHccVg4StxK9Jb49ij9i/870d71697172c76da3f89b0a915f2f31/xss)

Without <a href="https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)">cross-site scripting</a> protection, a view variable like the one above would be presented in a web page in the form of an annoying alert window, causing this form of attack called cross-site scripting. This may sound like a minor exasperation associated with more erudite attacks which might hasten the user to supply some bank information via a JavaScript model which are afterward sent to third-party websites.

Fortunately, when a variable is rendered within the `@{{}}` escape tags, Laravel will render in its place a string as the following one:

``` html  

My list &lt;script&gt;alert("spam spam spam!")&lt;/script&gt;

```

This makes Laravel applications immune to this type of attack.

![Laravel applications are immune to cross-site scripting attacks.](https://images.ctfassets.net/23aumh6u8s0i/7xUbSMIc5Lk3AbaeYVoee6/f4cd107e4f6fb1dde34153fe2efe39b0/no-xss)

<include src="TweetQuote" quoteText="With Laravel, you can rest assured that the most common attacks will be handled by default."/>

<include src="asides/LaravelBackend" />

## Conclusion

As you may know, there are other things you must do to protect your mission-critical applications, such as disabling verbose error reporting to stop sensitive details about your application being made visible to a bad actor. Nevertheless, Laravel ensures a much more secure application by protecting again these common attack vectors, reducing the attack surface out-of-the-box.

Laravel is one of the reasons behind the renewed interest in the PHP developer community. Using a more secure base application and following the familiar model–view–controller (MVC) architectural pattern, it's popularity grew fast. As a free, open-source framework, created by [Taylor Otwell](https://twitter.com/taylorotwell) and based on Symfony, Laravel took over as the defacto framework within a few years of its introduction.

"production-ready"