william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

As AI agents become more autonomous, developers need to understand how they communicate. We compare two key agent communication protocols: Model Context Protocol (MCP) and Agent-to-Agent (A2A), explaining how they work and when to use them.

AI agents are no longer just chatbots answering trivia questions. They’re writing code, querying APIs, scheduling meetings, and even collaborating with other agents to accomplish tasks. As this evolves, developers are starting to ask: how do these agents actually work together? Two concepts come up a lot: Model Context Protocol (MCP) and Agent-to-Agent (A2A) communication.
Both terms show up often in AI architecture conversations, but they’re often discussed in different contexts or with varying levels of technical depth. In this post, we’ll unpack both concepts side by side in plain language, with practical context for developers.

## What Is Model Context Protocol (MCP)?

[MCP (Model Context Protocol), developed by Anthropic](https://www.anthropic.com/news/model-context-protocol), is a structured way to let AI agents access tools, APIs, or external resources. It acts like a universal toolbelt, giving agents a predictable way to understand what tools are available, how to use them, and what to do with the responses. This makes tools safe, structured, and reusable across different models or vendors.

It works by connecting an MCP client (typically the LLM-powered agent) to local data sources and/or remote resource servers, which manage access to external tools or datasets.

![](https://images.ctfassets.net/23aumh6u8s0i/6FFOU4oh4xt8zGwx0UDYnK/d22d2b9f198bd30e559be1023028bc42/Copy_of_Auth0__Flow_Chart_Templates.png)

### How MCP works

At a high level, MCP is about helping an AI agent figure out what tools it can use, what they do, and how to call them safely. It’s like setting up a toolbox and giving the agent an instruction manual, instead of poking random APIs.

Here’s how a typical flow might go:

1. The user asks something the agent can’t answer with its current knowledge.
2. It realizes it needs outside info, like data from an API or a tool to crunch numbers.
3. If required, the user gets prompted to approve access.
4. The agent sends a structured request to the MCP server asking for what it needs.
5. The MCP server checks if the agent has permission and returns the result.
6. That fresh data or tool output gets added into its working memory.
7. Now the agent can respond with more accuracy and context.

MCP simplifies tool access and enforces safe, structured use of external resources without requiring the agent to understand the internal workings of those tools.

Learn more about MCP by reading [this introduction blog post](https://auth0.com/blog/an-introduction-to-mcp-and-authorization/).

<include src="LinkCard" link="https://auth0.com/blog/an-introduction-to-mcp-and-authorization/" title="An Introduction to MCP and Authorization
" description="Discover the Model Context Protocol (MCP) and its authorization mechanisms. Learn how to use API keys, OAuth 2.1 implementation, and best practices for secure LLM API connections." img="https://images.ctfassets.net/23aumh6u8s0i/ImPbKVGMqKM4FMs9Flncw/f715edcaec63105c95189125436cc3a1/MCP_and_Authorization.jpg" />

## What Is Agent-to-Agent (A2A) Communication?

Agent-to-Agent (A2A) communication, a concept being defined by Google Cloud, is like agents chatting with each other to figure things out together sharing goals, dividing up work, and sometimes even debating the best way forward. It's more like teamwork than just calling tools, and it opens the door to more dynamic, flexible problem-solving.

In A2A, agents typically fall into one of two categories:

* **Client agents** initiate requests and coordinate tasks on behalf of the user.
* **Remote or Service** agents advertise specific capabilities and handle incoming requests.

This simple distinction helps keep communication clear and makes it easier for agents to find the right collaborators.

![](https://images.ctfassets.net/23aumh6u8s0i/1Cyhz5IaFdhmLPlvW0wBHw/3658f0b0d342db25e7f192e5fe575b78/a2a-protocol-diagram.png
)

### How A2A works

A2A is all about letting agents talk to each other using standardized protocols. These agents send and receive JSON messages over HTTP, often mediated by an A2A server. But before that can happen, there needs to be a layer of trust.

That’s where **Agent Cards** come in, self-descriptions that each agent publishes outlining what they can do, what protocols they speak, and what kind of requests they accept. These cards help agents find the right collaborators without giving away sensitive implementation details.

Here’s how a typical flow goes:

1. A user asks the client agent to complete a complex task.

2. That client agent realizes it needs help and breaks the job into smaller parts.

3. It reviews other remote agents’ cards to see who’s best for which task.

4. It sends requests to those remote agents, who get to work in parallel.

5. They share progress, respond with outputs, or even ask follow-ups.

6. The original agent pulls all the results together and delivers a final response.

This setup supports more flexible workflows where agents can specialize and dynamically coordinate with one another, especially useful for large, multi-step tasks that benefit from multiple perspectives.


Learn more about how Auth0 is collaborating with [Google Cloud to help define the A2A spec](https://auth0.com/blog/auth0-google-a2a/)

<include src="LinkCard" link="https://auth0.com/blog/auth0-google-a2a/" title="Secure A2A Authentication with Auth0 and Google Cloud
" description="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." img="https://images.ctfassets.net/23aumh6u8s0i/6cD3przXWPPg8VnQxAiZrb/58cfe480db806613aca0509efc57e30e/auth0-google0cloud-a2a.png" />

## MCP and A2A: Complementary, Not Competitive

Sometimes, these systems are blended:

* Each agent in an A2A system might use MCP to call their own tools
* Or, a single MCP-powered agent might spin up temporary agents to handle subtasks (LangGraph, AutoGen)

But they solve different problems:

* MCP extends *what a single agent can do*
* A2A expands *how agents can collaborate*

## Why This Matters for Identity and Security

As AI agents evolve, the need for secure, observable, and identity-aware access grows. Whether an agent is calling a tool via MCP or delegating to another agent via A2A, we need ways to:

* Authenticate agent identities
* Control what they can access
* Trace their behavior

At Auth0, we think a lot about these layers of trust and access. If your agents can make API calls or act on behalf of users, identity becomes just as important as it is for human users.

## Conclusion

MCP and A2A are not competing standards, they’re complementary building blocks for how AI agents operate. Knowing when to use one (or both) is critical for developers building the next generation of AI-native apps. Auth0 has a [MCP Server you can use today](https://github.com/auth0/auth0-mcp-server) and learn more about [our collaboration with Google Cloud](https://auth0.com/blog/auth0-google-a2a/) on the A2A protocol. 


MCP vs A2A: A Guide to AI Agent Communication Protocols

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

Learn about the new classification of MCP servers as OAuth Resource Servers, implementing Resource Indicators to prevent token misuse, and the clearer security best practices designed to help you build more robust and secure MCP applications

As developers, we're building the next generation of applications on a foundation of interconnected services. The Model Context Protocol (MCP) is rapidly becoming a key part of that foundation, enabling seamless context sharing between AI models and applications. But as adoption grows, how do we ensure the connections we build are secure?

The [latest changelog](https://modelcontextprotocol.io/specification/2025-06-18/changelog), released on June 18, 2025, introduces updates that clarify how authorization should be handled for MCP Servers and how MCP Clients should implement [Resource Indicators](https://www.rfc-editor.org/rfc/rfc8707.html) to prevent malicious servers from obtaining access tokens.

Let's break down what’s new for auth and what it means for you as you build with MCP.

## MCP Servers Now Classified as OAuth Resource Servers

MCP servers are now officially classified as [OAuth Resource Servers](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#authorization-server-discovery). This might seem like a small semantic change, but it has significant implications for security and discovery.

By defining MCP servers this way, the protocol now includes a mechanism to add protected resource metadata. What does this mean in practice? It allows an MCP server to advertise where its corresponding Authorization Server is located. This discovery mechanism is vital for clients, as it removes ambiguity and ensures they request tokens from the legitimate, intended authority, streamlining the authorization process securely.

## Preventing Token Misuse by Implementing Resource Indicators (RFC 8707)

Have you ever worried about a token intended for one service being misused at another? This is a legitimate threat known as "token mis-redemption." To combat this, MCP clients are now required to implement Resource Indicators, as specified in [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707).

![A diagram illustrating MCP security, showing how Resource Indicators (RFC 8707) prevent token misuse by locking an access token to a specific audience (resource server)](https://images.ctfassets.net/23aumh6u8s0i/5H7veAQxKRIcnI6bOHWyEI/c2c6881322830a9283a5360af6906c68/Uploaded_from_Model_Context_Protocol__MCP__Spec_Updates_from_June_2025__One_Small_Step_for_a_Spec__One_Giant_Leap_for_Security)

By using a resource indicator in the token request, a client explicitly states the intended recipient (the "audience") of the access token. The Authorization Server can then issue a token that is _tightly scoped_ and only valid for that specific MCP server. This prevents a malicious or compromised server from taking a token it received and using it to access a different protected resource on the user's behalf. Put plainly, this practice ensures your tokens can't be used where they don't belong.

## Clearer MCP Security Guidance and Best Practices

Building secure systems is easier when the rules of the road are crystal clear. This update brings significant clarifications to the core [authorization spec's security considerations](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#security-considerations) and introduces a brand new, dedicated page for [security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices).

This new guidance provides actionable advice for developers like you and me so we can implement both clients and servers more securely. It centralizes security guidance, making it easier to build robust and secure MCP integrations from the ground up. We strongly recommend all developers working with MCP review these pages.

## Building a More Secure Future

These updates represent a significant step forward in hardening the Model Context Protocol. By formalizing the roles of servers, mandating token protection with resource indicators, and providing clearer documentation, the MCP is becoming an even more robust and trustworthy standard for the AI application ecosystem.

While these aren’t the only changes in the June 18th MCP specification changelog, they are the most impactful ones concerning authentication and authorization. If you are building and securing MCPs you should check out our documentation on Auth for MCP and the Getting Started with Auth0 Model Context Protocol (MCP) Server.

Now you’re ready to go forth and enhance the security of your MCP servers and clients.

Model Context Protocol (MCP) Spec Updates from June 2025: One Small Step for a Spec, One Giant Leap for Security

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/a2a-samples/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

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

Discover the Model Context Protocol (MCP) and its authorization mechanisms. Learn how to use API keys, OAuth 2.1 implementation, and best practices for secure LLM API connections.

An Introduction to MCP and Authorization

Haley Bourke

Sr. Site Reliability Engineer

A Beginner’s Guide to Understanding Password Authentication Protocol (PAP)

For modern developers, securing user data is more critical than ever. Ensuring that your applications implement reliable and effective authentication methods is a fundamental part of protecting both your users and your system.

[Password Authentication Protocol (PAP)](https://www.okta.com/identity-101/pap-security) serves as a starting point in understanding how to authenticate users. As one of the simplest such protocols, understanding how PAP works provides a foundation for a developer’s understanding of authentication. 

In this article, we will provide a high-level overview of PAP, surveying its role in application security as well as its limitations. We’ll see how leveraging platforms like Auth0 can help you to implement secure, scalable authentication, freeing you to focus on the best experience possible for your users. 

## So What Is It?

Password Authentication Protocol (PAP) is a method for authenticating human users (or devices, service accounts, etc.) by verifying their credentials.

PAP is used with Point-to-Point Protocol (PPP). PPP is a data link layer protocol used to establish direct communication between two network nodes. PPP supports various[ authentication protocols](https://www.okta.com/identity-101/authentication-protocols/), as we shall see. Before establishing a network connection between the two nodes (client and server), the identity of the client must first be verified via one of these supported protocols. 

PAP is just one of the protocols that PPP supports and is one of the simplest to understand. As we will see, PAP has its drawbacks, but its strength is its simplicity.

## Password Authentication Protocol (PAP) vs. Challenge Handshake Authentication Protocol (CHAP)

PAP is a two-way handshake: a client requests authentication, and a server responds. Passwords are delivered in plain text. The system then verifies that the credentials match what is stored for that user and responds with an ack or nack as appropriate.

You may begin to see a problem here. Since the password is sent across the network as regular text, PAP is not the most secure method.

In contrast to the two-way handshake and plain text password of PAP, CHAP is a _three-way_ handshake process.

In a system that uses CHAP, the server first sends a “challenge” to the client. This challenge could be a random string. The client then combines the challenge string with the user’s password and sends back a hash of the combination. If the client’s hash of the challenge + password combo matches the server’s, the user is authenticated.

As we can see, the CHAP process is more secure than PAP since the password itself in plain text is never sent across the network; only the challenge + password hash is. If that hash were to be intercepted, the hacker would not necessarily be able to decipher the user’s password. To provide additional security, the “challenge” word can be rotated periodically to ensure that if the challenge word were to be leaked or deciphered, the hacker would not be able to use it indefinitely to intercept and decipher traffic.

### Why Use PAP?

Now that you understand what PAP is and why CHAP can provide an extra layer of security, you may wonder, why use PAP at all?

Unfortunately, some systems, like certain legacy systems, may not support CHAP as a protocol. Some systems may also use multiple vendors under the hood when authenticating, each with differing CHAP variations, complicating implementations. In these cases, we may elect to use PAP in combination with some other layer or layers of security.

A hybrid approach is also an option: authenticate via the CHAP process if possible, but fall back to PAP if the CHAP method fails.

When using PAP, it is important to be aware of its limitations. It is a good idea to provide encryption at another layer of your system, for example, via SSL, TLS, or VPN.

## PAP and Auth0

While PAP is a foundational authentication method, as we have seen, its simplicity can pose security risks in modern applications. Implementing a robust and scalable authentication layer to your application can be difficult and time-consuming.

That’s where [Auth0](https://auth0.com/) comes in. With Auth0, you can easily implement and manage authentication in your application securely. Auth0 abstracts away the intricacies, saving valuable developer time while ensuring the highest security standards for your users.

## Recap

In this article, we learned about PAP and CHAP, their strengths and limitations, and when to use each of them.
Now that you have a basic foundation on authentication protocols, you may wish to explore more via the links provided below. 

## Additional Learning

* [Learn more about the security behind PAP](https://www.okta.com/identity-101/pap-security/).
* [Authentication Protocols 101](https://www.okta.com/identity-101/authentication-protocols/).
* [Oracle documentation on how to edit the PPP Path configuration file](https://docs.oracle.com/cd/E19096-01/sol.ppp301/805-4018/6j3qil152/index.html).
* [Academic article on Point-to-Point Protocol](https://www.sciencedirect.com/topics/computer-science/point-to-point-protocol).

What is Password Authentication Protocol?

arthur-bellore

I’m a tech content creator. I enjoy breaking up seemingly complicated topics into easy-to-understand pieces for people to read. When I’m not in front of a computer, you’ll usually find me reading books.

Cybersec Writer

Arthur Bellore

Transport Layer Security (TLS) is the cryptographic protocol behind pretty much any computer network used today: from web browsing to email, APIs, and VoIP. But how exactly does it work?

## SSL vs. TLS

SSL, or Secure Sockets Layer, is the predecessor to TLS. It was a cryptographic protocol developed by Netscape in 1994, but since it had serious flaws, it was never released to the public. SSL 2.0 was released publicly one year later, in 1995, but it, too, was found to have serious flaws. Finally, SSL 3.0 was rebuilt from the ground up and released in 1996.

Microsoft, who had its own version of the protocol, and Netscape agreed to hand over the project to the Internet Engineering Task Force (IETF) and make it an open standard. As part of the deal, the name was changed to TLS, Transport Layer Security, to signify that it no longer had ties with Netscape.

The first upgrade to SSL 3.0 was published in 1999 in [RFC 2246](https://datatracker.ietf.org/doc/html/rfc2246) as TLS 1.0. Tim Dierks, the editor of RFC 2246, has said [in his blog](https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html) that TLS 1.0 was really SSL 3.1, but they changed the name “so it wouldn’t look the IETF was just rubberstamping Netscape’s protocol.” Indeed, if you look at RFC 2246, it says:

This document describes TLS Version 1.0, which uses version { 3, 1 }. Version value 3.1 is historical: TLS version 1.0 is a minor modification to the SSL 3.0 protocol, which bears the version value 3.0.

TLS became the standard of encryption and authentication over computer networks, and it’s still being used today. The most recent version of the protocol is TLS 1.3, which was released in August 2018.

### What is the difference between SSL and TLS?

SSL hasn’t been updated since its release in 1996, and it was deprecated in 2015 in [RFC 7568](https://datatracker.ietf.org/doc/html/rfc7568). Most [modern browsers disable it by default](https://en.wikipedia.org/wiki/Version_history_for_TLS/SSL_support_in_web_browsers) or don’t support it outright anymore.

Despite this, because of the association between the two, many people still use the term SSL when they really mean to say TLS. Vendors typically use the same terms their target customers use to facilitate messaging, so their marketing collateral generally contains terms such as “SSL/TLS” or “SSL,” even though SSL is deprecated.

We now know that SSL and TLS are different things, but for the remainder of this article, SSL will be used interchangeably with TLS to match its everyday usage.

## Why SSL/TLS Was Created

For two computers to communicate with each other, they must perform a set of agreed-upon operations in a specific order. A **protocol** is what dictates those operations. The HTTP protocol is the protocol that web servers and clients use to establish a connection and communicate with each other through the Internet.

It works roughly as follows:

1. The server listens for new connections on port 80
2. The client connects to the server, and this starts a chain of operations as set forth by the HTTP protocol
3. The client sends a GET request to the server; the server receives the request, processes it, then sends back a response: headers and index.html, plus other content it might need to serve (CSS files, JavaScript files, cookies, etc.) for the client to render the content correctly.

This works to distribute content between two remote computers, but there is a problem: HTTP was intended to expand the local knowledge management tools throughout the multiple computers at CERN in the late 1980s, so it was designed as a clear text protocol.

Because it’s clear text, a malicious actor could insert themselves between client and server and potentially read sensitive information, such as credit card numbers or passwords, or they could intercept the client’s requests and serve back malicious files pretending to be server.

As the Internet evolved and the number of sensitive information flying around increased exponentially, an encryption layer sitting below HTTP was necessary. However, this is a bit tricky: if a bad actor can “listen in” the conversation between client and server while the connection is unencrypted, how can they exchange encryption keys securely?

One option would be for the two parties to create a public-private key pair and send over the public key pair to the other party, so they can use that to encrypt their packet before sending them over the wire.

The problem with this is that asymmetric (public-key) cryptography is _much slower_ than symmetric cryptography.

The "strength" of asymmetrical cryptography relies on modular arithmetic, mathematical operations that are very hard to do in the opposite direction. The numbers used in these operations need to be big enough to provide the necessary security, but performing arithmetic with very large numbers can be taxing on a CPU.

Symmetric cryptography, on the other hand, works differently and does not suffer from this problem. On top of that, most devices have AES instruction sets integrated into their CPUs to speed up AES operations, making AES encryption have almost zero overhead on modern devices.

The TLS protocol gets around this issue by using asymmetric cryptography to exchange keys at the beginning and then switch to symmetric keys (“sessions keys”) from then on in a process known as the TLS handshake.


## TLS handshakes

The exact steps of the TLS handshake will depend on which TLS version is supported by the client and server, as well as which parameters they are set to use.

Since most modern browsers still support TLS 1.2 and a lot of websites still use TLS 1.2 (according to a [paper published by Syed-Winkler](https://www.grin.com/document/1037281), as of February 2021, TLS 1.3 is supported by 42.9% of surveyed websites, while TLS 1.2 is supported by 99.3%), we will talk about TLS 1.2 first and then discuss how TLS 1.3 differs from 1.2.


### The TLS 1.2 handshake

TLS 1.2 can be configured to use many key exchange algorithms, and among them, the most well-known and widely used is the RSA key exchange algorithm. Let’s go over how the RSA algorithm works in TLS 1.2, then talk about how the process differs in TLS 1.3 with the [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) (DH) key exchange algorithm.

The RSA key exchange works roughly as follows in TLS 1.2:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** This message contains the TLS versions and cipher suites the client supports and a 32-byte random number known as Client Random.
3. **Server says “hello” back with a ServerHello message.** The server selects a cipher and the TLS version from the list provided by the client, then generates a different 32-byte random number known as Server Random and sends it all back along with the server’s own SSL certificate.
4. **Client uses the SSL certificate to verify the server’s identity.** SSL certificates contain a public key generated by the server and a digital signature signed with the private key of a trusted third party known as a certificate authority (CA). Most web browsers and operating systems come bundled with public keys from trusted CAs, which are used to verify that the CA issued the certificate.
5. **The client verifies the server has the matching private key to the certificate through ClientKeyExchange.** The client generates the pre-master secret (a 48-byte random number) and encrypts it with the server’s public key obtained from the certificate. If the server is the true owner of the certificate, it must be able to decrypt the message and obtain the original pre-master secret.
6. **Server decrypts the pre-master secret.** Now both the server and client have the pre-master secret, the Server Random, and the Client Random. They can use that to derive the master secret using the previously agreed cipher and arrive at the same (symmetric) key, which will become the session key once both parties verify their keys match.
7. **Client sends a ChangeCipherSpec message.** This indicates that the client is ready to create the session key and start communicating through an encrypted tunnel using that key.
8. **Client proves to server it has the correct keys.** The client hashes all handshake records up to that point, encrypts them with the session key, and sends them to the server. If the server generates the correct key, it will be able to decrypt that message and verify the record hashes (which the server can independently generate).
9. **Server proves to the client that it has the correct keys.** The server does the same thing and sends it to the client.
10. **A secure connection is established.** If both keys match, the TLS handshake is complete.

<br>
#### Problems with TLS 1.2

TLS 1.2 left a lot of its configuration parameters up to the users, which often resulted in bad choices (the old security adage of “among too many options, the worst one will be chosen”).

Additionally, in the name of backward compatibility, TLS 1.2 also allowed old, insecure ciphers to be used. (TLS 1.2 itself was released in 2008.) As time passed, it became more prone to attacks as vulnerabilities in older cipher or versions of TLS were discovered.

On top of all that, the RSA key exchange has a few weaknesses:

* **The same public-private key pair is used both to authenticate the server and to encrypt the pre-master secret (item #5 above).** If an attacker obtains the private key, they will be able to re-generate the session keys and be to decrypt the entire session.
* **There is no Perfect Forward Secrecy (PFS).** Since the server’s private key doesn’t change, an attacker might record and store encrypted data for years, hoping to decrypt it years down the line if the server’s private key is ever leaked or compromised.
* **Performance.** It’s necessary to make two round trips between the client and server until the session key is established.

To address these problems, the IETF began developing TLS 1.3 in 2013 and finally released it to the public in August 2018.

### What changed in TLS 1.3

In practice, the main differences between TLS 1.3 and 1.2 are:

* Shorter handshake
* Only supports key exchange algorithms with perfect forward secrecy (PFS), such as ephemeral Diffie-Hellman
* Support for 0-RTT (Zero Round Trip Time) resumption

This represents a bit of a paradigm change in TLS 1.3: shifting the focus from user configurability and backward compatibility to security by being more opinionated.

This allowed the designers to create a shorter handshake (by restraining DH as the only key exchange algorithm) but also prevented developers from choosing insecure options by restricting the number of options available in the first place.

For example, while it was technically possible to use DH as the key exchange method in TLS 1.2, the participants were responsible for setting the DH parameters. Picking the right parameters is crucial to make sure the DH exchange is secure, as some parameters can be trivially broken.

In 2015, security researchers [published a paper](https://weakdh.org/) describing how the WeakDH attack, which affected 8.4% of the top 1 million domains at the time, could trick servers into using small (insecure) DH parameters, enabling adversaries to decrypt data transmitted between client and server.

TLS 1.3 makes it impossible to use anything but a set of DH parameters that are believed to be secure.

### The TLS 1.3 handshake

Because there are significantly fewer options for the client and server to agree on, the TLS 1.3 handshake is much simpler:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** Since the list of cipher suites was vastly reduced in TLS 1.3 (from 37 to 5), the client assumes the server is going to use one of the five. It proactively calculates a key pair for each of the cipher suites and sends it to the server along with the protocol version.
3. **Server calculates the key session.** With the client’s key share, the server is able to generate the session key.
4. **Server says “hello” back with a ServerHello message.** The server generates its own key share and sends it over to the client, so it also can generate the session key, along with the server’s encrypted SSL certificate (using the session key created on #3).
5. **Client generates master secret and a secure connection is established.** The client receives the server’s key share and calculates the session key. It decrypts and verifies the server’s certificates, and if everything is good, the handshake is complete.

Note that there are two different public-private key pairs on an ephemeral DH exchange: the first is the ephemeral pair, created every time client and server establish a connection, which guarantees forward secrecy. The second pair, embedded on the SSL certificate, is used for authentication and doesn’t change.

Given that a new key is generated for every session, this feature guarantees PFS. If the encryption keys are compromised at a later date, the leaked key will only be able to decrypt the specific session to which it corresponds; all the prior sessions are still safe. As a result, large-scale storage of data transmitted between server and client is rendered worthless.

## How Auth0 Can Help

The temptation to intercept, undermine, and circumvent encryption has never been stronger. Cybercriminals are working to find ways to get around the issues that strong encryption presents due to the volume of valuable information that is sent between computers today.

While this rarely results in direct assaults against cryptographic algorithms or protocols, it frequently prompts attackers to devise novel methods of intercepting or capturing information. With these threats ever present, it is more crucial than ever to focus on maintaining strong and up-to-date implementations of effective encryption protocols.

Some applications are still running TLS versions older than 1.2, and others are still running the original SSL protocol. If yours is one of them, you should consider upgrading it immediately. Auth0 [supports both TLS 1.2 and TLS 1.3](https://auth0.com/docs/customize/custom-domains/self-managed-certificates/tls-ssl) and can help you keep your applications secure.

The TLS Handshake Explained

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

Should developers know Identity protocols like OIDC and OAuth, or should they only rely on high-level abstractions like SDKs?

Do developers need to understand the underlying details of OpenID Connect, OAuth, and other standards to implement authentication and authorization? Maybe yes, maybe no. Let’s explore some different points of view.

## The Hard Journey to Identity

Sooner or later, a developer will have to deal with authentication and authorization, whether they are building a SPA, an API, a mobile app, or a microservice, whether they are using Java, C#, JavaScript, or other programming languages.

Some will probably try to implement a homemade solution because it is, after all, a simple login box 😱. And after overcoming the hurdle of username and password authentication, they face the burden of [single sign-on](https://auth0.com/docs/authenticate/single-sign-on), delegated authorization, [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication), and so on. Perhaps just by trying to build a homemade solution, they will understand the complexity of the problem and look for proven solutions.

As they learn about standards such as [SAML](https://auth0.com/blog/how-saml-authentication-works/), [OIDC](https://auth0.com/docs/authenticate/protocols/openid-connect-protocol), [OAuth](https://auth0.com/docs/authenticate/protocols/oauth), [WebAuthn](https://auth0.com/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn), etc., they will probably realize that they have tried to reinvent the wheel. And most likely, they have not considered scenarios that could compromise the security of their application.

But even if you look at these standards from a high level, you will realize that there are many facets, many different scenarios to consider, several details and nuances.

In summary, sooner or later, developers will learn that Identity management is hard.

## To Know or to Ignore? That Is the Question

Once they understand that following standards is the high road to managing the identity of their application users, developers are at a crossroads:

1. Understand and implement the details of these standards.
2. Use a library or SDK and completely ignore the underlying complexity.

The two options seem divergent: know the details or ignore them altogether. Perhaps they reflect the two approaches that developers can take to deal with standards, not just in the Identity space. The choice may depend on the developer's inclination but also on other factors, such as competencies, available time and budget, and so on.

### Developers don't care...

[Someone has argued](https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect) that "*99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC, or any other security specifications. All they want to do is find the simplest and most straightforward way to support user authentication and authorization in their application. They don’t care about standards, specifications, grant types, JWTs, or scopes and timeouts – all they want to do is log a user in and check to see what permissions they have.*"

That's pretty understandable. As a developer, I want to solve my problem as quickly as possible without getting lost in the details. If I'm developing an e-commerce application, I want to focus on the business logic of my application. I don't want to worry about every technical detail that my application relies on. I don't want to know the little internal details of the framework my application runs on, the necessary compilation steps, or the network infrastructure that it will use. I prefer to use tools that take care of that and abstract the internal behavior. Tools that are accurately built by real experts in their field. After all, that is what we at Auth0 are trying to do: take care of the complexity of Identity and free developers from knowing the details of standards and security issues.

### ...developers do care

On the other hand, there are [those who argue](https://www.scottbrady91.com/oauth/why-developers-do-care-about-oauth-and-openid-connect) that "*there is an appetite from developers to learn more about OAuth and OpenID Connect and how to use them effectively. So maybe it’s a little too much to state that developers don’t care.*"

Well, in my experience, that is also true. I've found a lot of developers trying to understand how to properly use an [access token](https://auth0.com/docs/secure/tokens/access-tokens) and which [OAuth flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) to use in a given scenario, even if they're using a third-party library. And I think that's pretty understandable as well. While I don't want to learn every little detail of the infrastructure my application will run on, I can't ignore it completely. Some features of my application might depend on it to work well.

So, what is the right choice to make when dealing with standards in the Identity management space (and also in other areas)? Know their details or ignore them?

<include src="ebook-ads/JwtHandbook" />

## The Third Way

“[Zen and the Art of Motorcycle Maintenance](https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance)” is one of the cult books of the 1970s. It is a kind of philosophical novel in which the author, [Robert M. Pirsig](https://en.wikipedia.org/wiki/Robert_M._Pirsig), explores the concept of quality by interweaving it with his almost-fictional biography and his passion for motorcycles.

### Two types of developers

In one of the book's disquisitions, the main character divides humanity into two types:

- Those who see the world as a complex mechanism to be explored in its inner workings (*classical understanding*).
- Those who see the world primarily in its superficial appearances (*romantic understanding*).

Romantic people are those who ride their motorcycles without worrying about how they work. They are not interested in the mechanics of the drivetrain or the ignition or the lubrication system. If their motorcycle breaks down, they take it to the mechanic. And they hardly hear in advance that something is going to break down.

Classical people are those who feel their motorcycle. When they ride it, they hear every little noise, they imagine the movement of the chain, they are one with their means of transportation. They feel when something is about to go wrong because they know every little part of their bike and prefer to fix it themselves.

These two categories of people also apply to developers, in my opinion. Romantic developers don't care about the underlying technology or standard. They want to use a library that simplifies their lives and gets right to the point. Classical developers, on the other hand, want to know what happens inside a library: what technology, standard, and algorithm it uses. Classical developers are the traditional hackers, the ones who get their hands dirty with grease to fix or customize the engine of their motorcycle.

Maybe the choice between the two options for dealing with Identity management is driven by these two developer personalities. And perhaps each of you can identify with one of these two profiles.

<include src="BigQuote" quoteText="Although motorcycle riding is romantic, motorcycle maintenance is purely classic." quoteAuthor="R. M. Pirsig" />

### In medio stat virtus

Starting from a *classical* position, the protagonist realizes that virtue lies in the middle, just as the Latins used to say (*in medio stat virtus*). And virtue, excellence, quality is what he is looking for: what the ancient Greeks called *areté* and Eastern cultures call *Dharma*.

While each developer tends to use a romantic or classical approach to the Identity management problem, based on their personal nature, I think that each of the two positions should only be a starting point.

If Identity management is not your business, it is not cost-effective to implement standards from scratch and take care of all the details. Standards evolve, as do scenarios, best practices, etc. If your core business is not Identity management, implementing OIDC, OAuth, and the other standards may be too expensive and risky for your project.

On the other hand, simply using a library or SDK and ignoring what lies beneath it cannot last long. It can be frustrating when problems occur and you have no idea what is going on. You don't know if the problem depends on your code, your configuration, your library, the environment your application is running in. Understanding at least at a high level how the library you are using works and what standards it uses can help you at least to narrow down the area of investigation when problems occur.

In summary, I think every developer has their own starting point for dealing with problems. But whether you decide to do everything yourself based on standards or prefer to ignore everything under a library, in either case, it will impact the cost of your application.

I think the best solution is to get a medium level of expertise in technologies and standards so that you can at least choose your library with knowledge. What do we call this type of developer? The *pragmatic developer*?

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## What Auth0 Offers

Whether you are a romantic or classical developer, Auth0 helps you integrate authentication and authorization into your applications by letting you use the approach you prefer.

You have [SDKs and libraries](https://auth0.com/docs/libraries) that abstract the complexity of Identity management, but you are not locked into using our libraries. Your choice is free. But you can look into [our code](https://github.com/auth0) and contribute.

You also have [documentation on standards](https://auth0.com/docs/authenticate/protocols), [guides](https://developer.auth0.com/resources/guides) specific to your favorite framework, [code samples](https://developer.auth0.com/resources/code-samples), [videos](https://www.youtube.com/oktadev), and a [community](https://community.auth0.com/) to share what you've learned.

You can choose your preferred path to becoming a *pragmatic* developer by taking advantage of the resources Auth0 provides.

What kind of developer are you? Are you romantic or classical? Are you aiming to become a pragmatic developer? How can we help you? Leave your comments below.


Zen and the Art of Identity Management

vincenzo-chianese

Vincenzo Chianese is an Italian Software Developer focused on Web APIs and User Interfaces. He has been working for the last years in API companies such as Apiary, Oracle, LunchBadger, Stoplight. Currently, he is working for Microsoft to help move Microsoft Graph forward and authored some open-source tools in the market (Prism, Express Gateway).

API Architect

Vincenzo Chianese

A quick introduction to the new Protocol class in Python 3.8 and how it enables structural typing

## Introduction

In the [previous installment](https://auth0.com/blog/typing-in-python/), we have seen how to type annotations enable gradual typing in Python and some of the common typing patterns that Python developers use when writing code.

In this article, we're going to take a look at the new Protocol classes introduced in Python 3.8 and how it enables, even in typed contexts, structural typing, and other idiomatic patterns in Python.

## What Is A Protocol

Protocol is a very generic word, both in regular language as well as in Computer Science. Most of us are probably familiar with it from hearing **TCP Protocol**, **UDP Protocol** or also **HTTP Protocol**. Dictionaries have also dedicated definitions for it:

> A set of rules governing the exchange or the transmission of data between devices

Which indeed makes sense. All the examples listed above are communication _protocols_ between two remote devices with a set of rules that are governing the transmission. In the case of TCP, for instance, the protocol mandates the shape of the message, the possible operations, the error policies as well as the rules for possible retransmission of a message.

On the other hand, it might be kind of weird for people to talk about protocols in a programming language. After all, there is no communication involved in a program, so what is the meaning of it?

We can answer the question by taking a look at another more generic definition that is not coupled with computer science:

> The accepted or established code of procedure or behavior in any group, organization, or situation. (New Oxford Dictionary)

Let's notice the difference with the previous definition we found above:

* No **devices** involved.
* No data **transmission** involved.
* No **data** involved, per se.

In fact, the nature of the protocol we're going to be talking about today. By removing some of the constraints of the previous definition, it is possible to reason about protocols in the context of a programming language.

Protocols are indeed not a new idea and have been around for a long time. For instance, Clojure supports protocols explicitly.

```clojure
(defprotocol Shape
  (area [_])
  (perimeter [_]))
  
(defrecord Square [l])

(defrecord Circle [r]
  Shape
  (area [_] (* Math/PI (Math/pow r 2)))
  (perimeter [_] (* r Math/PI)))

(defrecord Rectangle [w h]
  Shape
  (area [_] (* w h))
  (perimeter [_] (* 2 (+ w h))))
```

This code is basically creating a set of functions grouped in a Protocol called `Shape`; every type that wants to adhere to such Protocol has to implement such methods.

Successively, we create two new types — `Circle` and `Rectangle` where we implement the `area` and `perimeter` methods that are defined in the protocol. Because of this, we can call any of the protocol methods on any of the type instance implementing it:

```clojure
(def c (->Circle 10))
(area c)
; 314.1592653589793

(def r (->Rectangle 10 12))
(area r)
; 120

(def s (->Square 10))
(area s)
; Execution error (IllegalArgumentException) at user/eval147$fn$G (REPL:1).
; No implementation of method: :area of protocol: #'user/Shape found for class: user.Square
```

We can see that the methods are called correctly in the first two instances, but it fails on the `Square` object because it does not implement the `Shape` Protocol. Also, note that no **class** or **inheritance** is involved in this.

It is also possible to implement a protocol on a type that is already existing, even on types we do not own:

```clojure
(extend-protocol Shape
  Square
  (area [s] (Math/pow (:l s) 2))
  (perimeter [s] (* 4 (:l s))))
  
(extend-protocol Shape
  java.lang.String
  (area [_] 1)
  (perimeter [_] 10))
  
(def s ->Square 10)
  
(area s)
; 100.0

(area "hello world")
; 1
  
```

In this example, we have indeed implemented the same protocol on a type that has been precedently created (`Square`) and then even implemented the protocol on the built-in `String` type. This allows us to obtain what is called "polymorphism a la carte", where classes and inheritance are not involved/required. The original type is not even aware that a protocol implementation is being attached to it.

The rationale behind the Protocols is well explained in [Simple made easy](https://www.youtube.com/watch?v=kGlVcSMgtV4) or in the [documentation page](https://clojure.org/reference/protocols)

## Protocols In Python

Protocols in Python work a little bit differently. While the concept is the same as Clojure, Python does not need explicit protocol declaration. If a type has the methods specified in the protocol, then it implements the protocol.

For instance, the [len function](https://docs.python.org/3/library/functions.html#len) requires a `Sized` type as its argument, which is every type that implements the `__len__` function:

```python
class Team:
    def __init__(self, members):
        self.__members = members

justice_league_fav = Team(["batman", "wonder woman", "flash"])

print(len(justice_league_fav)) # TypeError: object of type 'Team' has no len()
```

The `Team` class does not implement the `__len__` method, and the runtime is throwing an error. We can change the class to implement such method:

```python
class SizedTeam:
    def __init__(self, members):
        self.__members = members

    def __len__(self):
        return len(self.__members)

justice_league_fav = SizedTeam(["batman", "wonder woman", "flash"])

print(len(justice_league_fav)) # 3
```

In the same way, we have seen in Clojure, no inheritance was involved, and the runtime has been able to execute the code.

Python 3 defines a number of protocols that can be implemented by our own types to be used around. The most common ones are:

* `Sized`: any type implementing the `__len__` method
* `Iterable`: any type implementing the `__iter__` method
* `Iterator`: any type implementing the `__iter__` and `__next__` methods

The complete list, though, is available on the [documentation page](https://mypy.readthedocs.io/en/stable/protocols.html)

## Protocol Types In Python

The problem comes when we try to apply the same Protocol concept in a typed context. Suppose, for instance; we have a custom class defining a protocol describing an open/close method for IO operations:

```python
import io

class IOResource:
    def __init__(self, uri: str):
        pass

    def open(self) -> int:
        pass

    def close(self) -> None:
        pass


class FileResource:
    def __init__(self, uri: str):
        self.uri = uri

    def open(self):
        self.file = io.FileIO(self.uri)
        return self.file.fileno()

    def close(self):
        self.file.close()


def write_resource_to_disk(r: IOResource):
    pass


write_resource_to_disk(FileResource("file.txt"))
```

Try to paste this code in a new file called `IOResource.py` and then try to run [`mypy`](http://mypy.readthedocs.io) on it:

```bash
mypy IOResource.py

IOResource.py:11: error: Argument 1 to "write_resource_to_disk" has incompatible type "FileResource"; expected "IOResource"
```

You can see we received a type error claiming (rightfully) that `FileResource` is not an `IOResource` subclass, even though our class is implemented all the required methods.

The same also happens to the builtin collection types, in case we're using Python 3.7 and running an older version of mypy (0.521, to be specific) on the following code:

```python
from typing import Sized

def multiply_len(val: Sized) -> int:
    return 2 * len(val)

class SizedTeam:
    def __init__(self, members):
        self.__members = members

    def __len__(self):
        return len(self.__members)

multiply_len(SizedTeam(["batman", "wonder woman", "flash"]))

# team.py:13: error: Argument 1 to "multiply_len" has incompatible type "SizedTeam"; expected "Sized"
```

Basically, the type system is **not** smart enough to recognize the implicit protocol through structural typing, leaving a bunch of idiomatic Python constructs out of the game when working in typed contexts.

Fortunately speaking, the issue has been fixed in Python 3.8 (or with any mypy >= 0.521) with the introduction of [Protocol classes](https://www.python.org/dev/peps/pep-0544/). If we take the collection example from above and try it on Python 3.8 — it will indeed work.

We can also fix now the `IOResource` example to make it work in Python 3.8:

```python
import io
from typing import Protocol

class IOResource(Protocol):
    def __init__(self, uri: str):
        pass

    def open(self) -> int:
        pass

    def close(self) -> None:
        pass


class FileResource:
    def __init__(self, uri: str):
        self.uri = uri

    def open(self):
        self.file = io.FileIO(self.uri)
        return self.file.fileno()

    def close(self):
        self.file.close()


def write_resource_to_disk(r: IOResource):
    pass


write_resource_to_disk(FileResource("file.txt"))
```

If we try to run mypy on this file again, we should receive no error.

The only change that was required was to make the base class inherit from a new special class called `Protocol`. This is a special class that enables the type system to go structural and not nominal.

## Rundown of Protocols Features

Let's now consider this protocol class:

```python
from typing import Protocol
import io

class IOResource(Protocol):
    uri: str

    def __init__(self, uri: str):
        pass

    def open(self) -> int:
        pass

    def close(self) -> None:
        pass
```

And let's use it to check what we can do when using Protocols.

Protocols are defined by including the special `typing.Protocol` class in the base class list. The annotated class does not lose any semantics of a regular abstract base class; they are just handled specially by the type checker.

All the functions and variables of a Protocol class are also protocol members, no matter the decorator on the top. This means they have to present in the target classes in order to consider them compliant with the protocol:


```python
import io


class FileResource:
    data: str
    file: io.FileIO

    def __init__(self, uri: str):
        self.data = uri

    def open(self):
        self.file = io.FileIO(self.uri)
        return self.file.fileno()

    def close(self):
        self.file.close()



write_resource_to_disk(FileResource("file.txt")) # Argument 1 to "write_resource_to_disk" has incompatible type "FileResource"; expected "IOResource"

```

When running this code through mypy, the type checker will detect the class is missing the `uri` string property that's defined in the protocol class.

A class can also inherit directly from a Protocol class — making the relationship explicit. This does not change anything, and it is indeed not required (and discouraged):

```python
- class FileResource:
+ class FileResource(IOResource):
```

A Protocol class can also aggregate other protocols if necessary:

```python
- class IOResource(Protocol):
+ class IOResource(Sized, Protocol):
```

In this case, the IOResource is a protocol with the methods we have defined above **and** it's also a `Sized`, meaning the `__len__` method must be implemented:

```python
class FileResource():
    uri: str
    file: io.FileIO

+    def __len__(self):
+        return len(self.file.readall())
```

It is also possible to create "aggregate" protocol classes, if necessary:

```python
from typing import Protocol
import io

class IOResource(Protocol):
    uri: str

    def __init__(self, uri: str):
        pass

    def open(self) -> int:
        pass

    def close(self) -> None:
        pass

class SizedIOResource(IOResource, Sized, Protocol):
  pass
```

Any class willing to adhere to the `SizedIOResource` protocol has to implement all the methods in `IOResource` and the `__len__` method as well.

Protocol classes cannot be instantiated, and both a typing error and a runtime error will be thrown since they're internally abstract classes:

```python
q = IOResource("/dev/file.txt") # Cannot instantiate abstract class 'IOResource' with abstract attributes '__len__' and 'uri'
```

## Conclusions

Protocol classes are very useful to keep some idiomatic patterns in Python, even in typed contexts. While the type system is yet not complete, this is an important milestone to close the loop of the story.

Protocol Types in Python 3.8

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

Identity protocols for internet browsers with Sam Goto (Google Chrome) and George Fletcher (Verizon)

## The Overview

In this episode of _Identity, Unlocked_, principal architect at Auth0 and podcast host Vittorio Bertocci speaks with Sam Goto, software engineer working on Google Chrome, and George Fletcher, Identity Standards architect at Verizon, on the ever-changing world of identity protocols for internet browsers.

Sam focuses on working with browsers to create better functionality in their foundation protocol by determining the good and bad uses of low-level primitives, such as third-party cookies, iFrames, and pop-ups. In particular, Sam highlights how such primitives are being used by trackers and ad services to track users, often without their knowledge or consent- and how that is prompting browser vendors to put new limits to prevent abuses. There is a precedent for this: Sam gives the example of how over time, web apps increasingly abused low-level primitives such as pop-ups- and how browsers eventually put restrictions on them to give a better user experience. Browser vendors are now attempting to do the same to prevent unwanted tracking; however, those interventions are disrupting legitimate scenarios too- identity protocols being one of the most important ones, and the very reason we are having this conversation on Identity, Unlocked. Sam then talks about how browsers are looking to fix these problems by building higher level primitives to replace the low-level ones, but that even these high-level primitives face challenges.

George explains the many problems the modifications to browsers can cause for Identity and OpenID Connect. George also goes into detail about the protocols being implemented between browsers, relying on parties and IdPs for what happens if an IdP goes down, as well as the RP classification and decentralized identity.

Vittorio, Sam, and George go in depth on the state of browser changes and identity protocol today and what’s in store for their futures.

## Key Takeaways

Distinguishing between good and bad motives of low level primitives:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/da8f4e71"></iframe>

What’s happening to identity protocols as browser authentication changes:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/7a5f49ee"></iframe>

Sam talks about the potential for other browsers to integrate Web ID and the new challenges that would come about:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/38619c76"></iframe>

George points out key problems to solving the RP classification problem:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/3445437a"></iframe>

George’s Call to Action:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/6baaec0f"></iframe>

Sam’s Call to Action:
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/4a98766b"></iframe>


### Links/Resources:

- Connect with Sam Goto on [LinkedIn](https://www.linkedin.com/in/samuelgoto/)
- Connect with Sam Goto on [Twitter](https://twitter.com/samuelgoto)
- Connect with George Fletcher on [LinkedIn](https://www.linkedin.com/in/gffletch/)
- Connect with George Fletcher on [Twitter](https://twitter.com/gffletch)

<br>

- Connect with Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)
- Connect with Vittorio Bertocci on [Twitter](http://www.twitter.com/vibronet)

<br>

- Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)
- Learn more about [Auth0](https://auth0.com/)
- Learn more about the sponsor for this season, the [OpenID Foundation](https://openid.net/foundation/)

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />

Identity, Unlocked... Explained: Season 2 Ep 7

Continuous Access Evaluation Protocol (CAEP) with Tim Cappalli and Atul Tulshibagwale



Tune in to this episode of the Identity Unlocked podcast, where host Vittorio Bertocci focuses on the [Shared Signal and Events (SSE) working group](https://openid.net/wg/sse/) in the OpenID Foundation. This podcast is all about discussing identity specifications and trends from a developer's perspective. The podcast is powered by [Auth0](https://auth0.com/); this season is sponsored by the [OpenID Foundation](https://openid.net/foundation/). 

Welcoming two guests to this episode, Vittorio asks Microsoft Digital Identity Standards Architect Tim Cappalli and Senior Staff Software Engineer at Google, Atul Goel, to share a bit about their backgrounds, bringing them into the identity field. While their trajectories looked quite different, both Tim and Atul ended up landing close to one another in the identity space. 

The discussion quickly moves to the main topic of the episode, introducing the scenarios and motivations behind the SSE working group activities as well as some of the key contributors &mdash; Microsoft, Google, Sailpoint, AWS, Target, SalesForce, Cisco, among many others.

Vittorio digs deeper into this conversation to learn about their dependence and the details of the [Continuous Access Evaluation Protocol (CAEP)](https://bitbucket.org/openid/risc/src/caep-draft-01/). Tim and Atul take turns in digging in the details of CAEP, its dependency on the [Security Event Token specification (SET)](https://tools.ietf.org/html/rfc8417), and how its features are complementary with the ones defined by [SCIM](https://tools.ietf.org/html/rfc7644) and [FastFed](https://openid.net/wg/fastfed/), other specifications we'll soon cover on the show. In particular, the discussion touches on the typical scenarios CAEP is designed to address, some of the mechanisms behind it (event and messaging, etc.), and how Microsoft has been leveraging CAEP in its own solutions to handle some of the challenges the exponential increase in usage brought by COVID presented. The episode comes to a close as Atul issues a call to action: keep an eye on the [CAEP specification](https://bitbucket.org/openid/risc/src/caep-draft-01/) and contribute your comments as the document progresses thru the standardization process.

## Key Takeaways 

**[7:10]** - How the identity landscape has changed
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/0b1e7d19"></iframe>

**[09:50]** - Who are the main actors and how many different components of a network and security system would be involved?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/59bfd9b4"></iframe>

**[11:24]** - Names active in this space, a very diverse group
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/5f9d44bc"></iframe>

**[12:04]** - Dependence primarily on the security event tokens
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/e4836f63"></iframe>

**[14:12]** - Tim weighs in on the debate regarding less specific identifiers
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/4a91f9e3"></iframe>

**[16:24]** - Digging deeper into CAEP
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/276a9f93"></iframe>

**[21:34]** - More practical scenarios of where this setup would be useful
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/d1a42aa5"></iframe>

**[28:30]** - Where are we now in the discussion? 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/d1a42aa5"></iframe>

### Links/Resources:

Connect with Tim on [Twitter](https://www.twitter.com/timcappalli)<br />
Connect with Atul on [Twitter](https://twitter.com/googatul)<br />
Connect with Vittorio Bertocci on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Find out more on [Auth0](https://auth0.com/)<br />
Learn more about the sponsor for this season, the [OpenID Foundation](https://openid.net/foundation/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained: Season 2, Ep 3

tim-ferrell

I enjoy meeting the complex technical challenges that Auth0 faces with the support that I get through the company's unique culture and distributed workforce. It’s truly empowering.

Engineer

Tim Ferrell

Learn about the engineering principles, technology, and goals behind the gRPC system by setting up a service.

Creating a Node gRPC Service Using Mali

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Learn how to easily and quickly prototype JavaScript apps using ParcelJS.

Zero Config JavaScript App Prototyping with ParcelJS

Learn how to easy prototype JavaScript apps using the zero config feature of Webpack 4.

Zero Config JavaScript App Prototyping with Webpack

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

Leading tech companies join forces to create protocols around identity data



**BELLEVUE, Wash. -- May 8, 2018 --** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that it has joined the [Decentralized Identity Foundation](http://identity.foundation/) (DIF) to collaborate and provide insight on creating a standards-based ecosystem for managing digital identities. Initiated by executives from Microsoft, uPort, Gem, Evernym, Blockstack, and Tierion, the Decentralized Identity Foundation addresses an ever increasing need for governance around identity and authentication.

Auth0 will work alongside companies such as IBM, Accenture, RSA, IDEO, and others within the foundation to create specifications for securing and accessing identity data. The three foundational elements of a decentralized ecosystem are to:

1) Enable registration of self-sovereign identifiers that no provider owns or controls;

2) Offer the ability to look up and discover identifiers and data across decentralized systems;

3) Provide a mechanism for users to securely store sensitive identity data, and enable them to precisely control what is shared with others.

“Digital identity is the core of every interaction, transaction, and communication online, but it’s a little like the Wild West right now in terms of standards and specifications around how identity could be handled in a decentralized manner,” said Martin Gontovnikas, Vice President of Marketing at Auth0. “There is an important need for strong voices to shape the future of this industry, and we are looking forward to our involvement with the Decentralized Identity Foundation.”

<include src="asides/AboutAuth0" />

### Media Contact

Jeana Tahnk<br>
Corporate Communications<br>
Auth0<br>
[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)

Kasia Hall<br>
Matter for Auth0<br>
[khall@matternow.com](mailto:khall@matternow.com)<br>
971-246-7898


Auth0 Joins Decentralized Identity Foundation

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Former Auth0 Employee

Robin Percy

A new security vulnerability has been found in the WPA2 WiFi protocol.  We will look at the details of this, and how to mitigate it.



**TL;DR:**  A new security vulnerability has been found in WPA2 (the protocol that secures almost every modern WiFi connection).  The security weakness potentially allows a sinister agent, within range of the network, to hijack traffic and view any sensitive communication that is not encrypted.  In this article we'll take a look at the vulnerability, the risk it poses to you, and how to mitigate it.


## What is it?

*KRACK*.  Or *Key Reinstallation AttaCK*.  This is the name given to the latest security vulnerability found within the WPA2 protocol, which the majority of us use to secure our WiFi networks.  The weakness could potentially affect *any* device that secures WiFi with WPA2.  Once exploited, a malicious agent would be able to steal sensitive information such as bank account details, user account details and passwords, etc.  It may also be possible for the malicious agent to inject and manipulate data such as Ransomware or Malware.

Discovered by the security researcher [Mathy Vanhoef](https://twitter.com/vanhoefm), the KRACK vulnerability has cast a dark shadow over the *proven-secure* WPA2 protocol, the very protocol that hasn't been destabilised in over 14 years.  From a high level, the vulnerability allows a malicious agent to intercept a connection between a WiFi network and device.  The malicious agent can then force the reinstallation of an already in use encryption key, by manipulating and replaying the cryptographic handshake process that happens between the device and network.  Once exploited, a malicious agent can access any unencrypted information sent over that network connection.

When a user goes to join a WiFi network, be it on their laptop, tablet or phone, a 4-way-handshake (4 step process) is initiated in which a fresh session key is negotiated.

The 4 step process is reflected in the following image, with the `AP` being the *Access Point (Network)* and the `STA` representing the device:

![WiFi 4-way handshake process](https://images.ctfassets.net/23aumh6u8s0i/5WM8Se3acljfPMs0U5IYct/1b2270474e02c13e126cbdae9acd9032/wifi-4-way-handshake)

After *step 3* in this process, the session key is installed and will be used to encrypt normal data frames.  The Access Point will retransmit step 3 of the handshake, however, if it does not receive an appropriate response or acknowledgement.  As a result of this, the client may receive step 3 multiple times, reinstalling the *same* session key each time, and thereby resetting both the *incremental transmit packet number (nonce)* and *receive replay counter* used by the data-confidentiality protocol.

Using the KRACK exploit, a malicious agent can force these *nonce* resets by replaying transmissions of step 3.  By forcing nonce reuse in this manner, the data-confidentiality protocol can be attacked.  Packets can be replayed, decrypted, and forged, leading to the theft of information, decryption of sensitive data and injection of malicious software.


## Who does it affect?

In short, the most vulnerable devices outed so far are *Android* and *Linux* devices due to the `wpa_supplicant` WiFi client that is commonly used.  That being said, this statement is taken directly from the vulnerability researcher, Mathy:

<include src="TweetQuote" quoteText="Any device that uses Wi-Fi is likely vulnerable to the KRACK vulnerability."/>

Unlike most vulnerabilities that are found in small or isolated components of systems, this vulnerability comes from within the WPA2 protocol itself.  The attack is against the 4-way handshake, and does not exploit access points themselves, but instead targets clients (devices such as laptops, tablets and phones).  This means that although a router may be updated and running the latest firmware, it is relatively unimportant, as whichever OS the connecting device is running on may be using the exploitable WPA2 protocol.

Although Windows, Mac and other brands are susceptible to this attack, as mentioned above, the most vulnerable are Linux based systems.  Quoting directly from the research paper, we can learn exactly why:

> " Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant (the Wi-Fi client commonly used on Linux). Here, the client will install an all-zero encryption key instead of reinstalling the real key. 

> When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall an all-zero key.  Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. 

> Note that currently **50%** of Android devices are vulnerable to this exceptionally devastating variant of our attack. "

The reason this vulnerability could be particularly dangerous in a public WiFi situation is because among other things, the key reinstallation attacks allow a malicious agent to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to **inject arbitrary data**. This enables one of the most common attacks over Wi-Fi networks: injecting malicious data into an unencrypted HTTP connection.  Although a particular threat to public WiFi, of course, this is still a potential threat at home too.

Take a look below at the exploit being demonstrated in action, bypassing WPA2 against ***Android*** and ***Linux.***

<iframe width="800" height="450" src="https://www.youtube.com/embed/Oh4WURZoR98" frameborder="0"  allowfullscreen></iframe>


## What does this mean for you?

Well, hopefully, not too much.  As we'll see in the *mitigation* section below, vendors are responding well to this exploit and patches are already widely available.  However, that does not necessarily mean we are automatically safe.  The research paper was actually written back in May, but held privately for review, to give vendors a chance to patch software.  Since the paper was written, Mathy and his team have actually found an even easier way of exploiting the 4-way-handshake:

> With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking **macOS** and **OpenBSD** is significantly easier than discussed in the paper.

If you are a user of Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, there is a good chance you may be affected by some variant of the attack.  Without wanting to make too many assumptions, I'm fairly sure that means pretty much all of us.  There is one caveat to this vulnerability though.  To exploit and manipulate the network connection, the malicious agent *would* need to be in range of the WiFi network.  This means that generally speaking, your home network is *relatively* safe, so long as your family and friends aren't avid hackers.  However, if you are a regular user of Public WiFi networks, it *could* be a much more bleak picture.

This vulnerability is also newly published, and there are (as of yet) no direct exploits available online for would-be malicious agents.  Because of this, and because Mathy will *not* release the code used to find and manipulate the vulnerability, the exploit would need to be entirely recreated by anyone who wished to use it maliciously.  That being said, the world is full of extraordinarily talented software engineers, and any one of them could use the research paper to reverse-engineer the exploit, and release their code at any time.

I am not intending to down-play this vulnerability, I fully understand how dangerous it could be, but it *is* being addressed and patched by vendors at a fantastic rate.  Another point to note here is that any network traffic with end-to-end encryption means a significant amount of the risk would be mitigated, as intercepted messages would not be able to be viewed so credentials and details could not be stolen.


## How to mitigate the situation

In this case, changing your WiFi network password or even swapping out your network router is not going to help.  The key to mitigating this vulnerability is ***patching your software.***  As I mentioned above, the vendor companies were informed of this vulnerability a few months ago, and most have been working away behind the scenes to release updates and patches.

For a full list of vendors who have already addressed this vulnerability, check out the [CERT Vulnerability Database](https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4) page.  As you will note, some of the biggest named vendors released patches quietly days / weeks ago.

Yesterday: 

- [Cisco](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa)  released security patches,
- [Intel](https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00101&languageid=en-fr) released security patches,
- [Netgear](https://kb.netgear.com/000049498/Security-Advisory-for-WPA-2-Vulnerabilities-PSV-2017-2826-PSV-2017-2836-PSV-2017-2837) released security patches and information,
- [Aruba](http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt) released a security advisory.

For Linux based systems:

- [OpenBSD](https://marc.info/?l=openbsd-announce&m=148839684520133&w=2) released WPA2 patches,
- [Debian](https://www.debian.org/security/2017/dsa-3999) also released patches.
- [Ubuntu](https://askubuntu.com/a/965685) fixes have been issued.

***Microsoft*** announced that they have included security patches in their October batch of security updates.  ***Apple*** have announced that they will be releasing macOS patches in the coming days, once tested.  ***Google*** have stated that patches for Android and ChromeOS will be released as soon as possible.

For other vendors, the [WiFi Alliance are working to mitigate](https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update).


## Conclusion

<include src="TweetQuote" quoteText="As with most security vulnerabilities, the most important thing to consider here is patching your software as soon as you can."/>

As with most large or small security vulnerabilities, the biggest thing to consider here is ***patching your software*** as soon as you can.  With new updates and patches being released on an almost hourly basis as the moment, keep an eye on your vendor to ensure you grab yours as soon as applicable.

This exploit has indeed come as a huge shock to the security industry.  Not only was WPA2 a mathematically *proven* technology, but it was also certified and trusted.  The fact that it has taken 14 years for this exploit to come to light is just as big a shock, though I believe we should be glad that it has.  And amicably too.

For all of the research I've done over the last couple of days, I cannot find any examples of this exploit being used in a malicious way, or in any past hacks.  As I mentioned above, and as one can see from the research paper, this is not a particularly easy vulnerability to exploit, however I can almost guarantee now that it's come to light, there will be many trying.  You can help to stop them succeeding by ensuring you update / patch your systems.

I think *thanks* are in order for [Mathy Vanhoef](https://twitter.com/vanhoefm).  Both for finding and researching this vulnerability, but for being incredibly mature and responsible in the way he diagnosed and reported it.

If you would like a detailed insight into the inner workings of this vulnerability, Mathy has released his findings in a [KRACK Vulnerability Research Paper](https://papers.mathyvanhoef.com/ccs2017.pdf).

Stay safe out there!

[ **- @rbin**](https://twitter.com/rbin)


**About Auth0**

Ensuring that one's hardware *and* software are both patched and kept updated to the latest version is the best way of avoiding security vulnerabilities.  Many of the most prevalent security concerns start with users and user credential management.  Happily, we can ensure our user management is as secure as possible.

Auth0, a global leader in Identity-as-a-Service (IDaaS), provides thousands of customers in every market sector with the only identity solution they need for their web, mobile, IoT, and internal applications. Its extensible platform seamlessly authenticates and secures more than 50M logins per day, making it loved by developers and trusted by global enterprises.

As a developer, you can [try Auth0 for free!](https://auth0.com/signup)  Sign up now to [get started](https://auth0.com/signup).

For more information, visit [https://auth0.com](https://auth0.com/) or follow [@auth0 on Twitter](https://twitter.com/auth0).


WPA2 KRACK Attack: The WiFi Hack and What it Means

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Auth0 conforms to OpenID Connect protocol and allows clients to verify the identity of the end-users though a reliable implementation.



In May of last year, Auth0 officially gained certifications for *OP Basic* and *OP Config* profiles of the OpenID Connect spec. As of February this year, Auth0 has gained two new [OpenID Connect certifications: *OP Implicit* and *Hybrid OP*](http://oixnet.org/openid-certifications/auth0/). With these certifications we're thrilled to join the ranks of industry leaders such as Google, Microsoft, PayPal, and others who are embracing standards based authentication.

OpenID Connect, as a layer on top of the OAuth 2.0 authorization protocol, allows for decentralized authentication and improves user access to websites and apps.

Getting certified means ensuring that our implementation of the protocol meets the official specifications as outlined by [OpenID](http://openid.net/developers/specs/).

OpenID is a cornerstone of the modern, open web, and we're proud that our implementation has the official stamp of approval.

## What Is OpenID Connect?

OpenID Connect is an open identity standard. It acts as an authentication layer (proving who you are) on top of the OAuth 2.0 authorization standard (granting you access).

A user gets an OpenID account through an OpenID identity provider. The user uses that account to sign into any site (a relying party) that accepts OpenID authentication (for example, YouTube). This open-source framework, provided by the OpenID standard, lets the user, relying party and the identity provider “just work” together.

Instead of having to sign up on a website and keep track of your passwords, you only need to sign up once and use that login across various applications.

On a website, it might look something like this:

![example login sign in form](https://images.ctfassets.net/23aumh6u8s0i/3r8PILdrCrl8YjOMtcHsjs/11f9e4d97cacc97cc89c76814fc4e22b/sign-in-form)

A user is already logged into Facebook or Google (an identity provider) with a set of credentials. This set of credentials can then be used to log into another website or application, a relying party. This site or app will ask the user "Sign up with Facebook or Google?"

When a user clicks on Google or Facebook, they're authorizing that identity provider to back up their claim. Then the user is redirected to the website or application.

![example social provider authorization](https://images.ctfassets.net/23aumh6u8s0i/0n2zFjciHBXn1YqTOzv7X/4f683da5c99cc18e95fb6814db9b658a/social-provider-authorization)

This use of linked identities means you only have to manage a single username and password for websites.

With OpenID, users don't need traditional authentication tokens like a username and password. All they need is to be registered on a site with an OpenID identity provider. It's decentralized; any website can use OpenID as a way to log users in.

<include src="ebook-ads/OidcHandbook" />

## Why is OpenID Connect Important?

Before OpenID, people built site-specific networks with their own signup and login systems. The idea that you could select your own identity provider for logging into a website and a common standard that would connect all these systems didn't exist. Some big players, like Facebook, had built their own solutions for SSO. But the decentralized OpenID model was so powerful and beneficial that even they eventually adopted it. Like VentureBeat's Eric Eldon [wrote](http://venturebeat.com/2009/04/14/single-sign-on-service-openid-getting-more-usage/) upon its release,

> *The point of OpenID, as all of these companies seem to accept, is that users don’t want to use just any one service to sign in everywhere. Instead, users should have the choice to log into any site using any other identity. Making it easier for people to log in anywhere just means more people will log in overall — and potentially become users of any of these companies.*

Think of OpenID as your driver's license for the entire internet.

Websites that use OpenID won't ask for your information constantly, making it faster and easier to sign up. Plus, you can associate information with your OpenID such as your name and email address, and decide how much websites get to know about you. So, websites that use OpenID won't bug you for the same information every single time you sign up.

Since you're uniquely identified over the internet, OpenID Connect is also a good way connect your accounts into a more unified persona. The moment you establish yourself as the individual who uses a specific OpenID, whenever someone sees you're using your OpenID online, they'll know it's you.

If your friend opens a website and sees someone with your OpenID has made a comment, they can be certain it was you, not someone with the same name coincidentally.

## Why Get OpenID Certification?

You've carried rounds and rounds of tests to check your OpenID specs. The results were great with strong participation. So what's the point of getting certified?

Certification ensures credibility. In your own testing, you can pick and choose what aspects of your OpenID implementation you want to test. Certification involves meeting a set of minimum criteria that are standard across the board, and your results (and the process you used to get there) are open for public oversight.

When you're done, you can prove that your [OpenID implementation](https://auth0.com/learn/how-auth0-uses-identity-industry-standards/) is conformant with the [official specs](http://openid.net/certification/) — not just for your customers and potential customers, but for yourself.

## Aside: Securing Applications with Auth0

Are you building a product and want to support OAuth and OpenID Connect? We at Auth0, can help help you with that while you keep focused on what matters the most to you, the special features of your product.

[Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication). [We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.


Auth0 is OpenID Connect Certified

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Protobuf, the binary format crafted by Google, surpasses JSON performance even on JavaScript environments like Node.js/V8 and web browsers.

"proto"