sara-kazemi

As a former computer science educator and software engineer, I joined Okta in 2021 to combine these skills to create engaging, accessible learning experiences for devs.

Senior Technical Curriculum Developer - Expert Acceleration

Sara Kazemi

We're excited to introduce [Okta Learning](https://learning.okta.com/), our new learning experience designed to help you level up your identity and access management (IAM) superpowers. With Okta Learning, you can develop new skills and earn valuable certifications that can help advance your career. Whether you're a seasoned developer or just getting started, Okta Learning offers self-paced, tailored learning paths and plans to help you master the tools and technologies you need to succeed in the world of digital identity.

## Personalized Learning Paths for Every Developer

We know that every developer has unique learning needs. That’s why we’ve built custom [learning paths](https://learning.okta.com/page/courses-all#swimlane-learningpaths) based on the specific skills you want to learn. Whether you're interested in leveraging Auth0 APIs and SDKs, integrating authentication protocols, or learning how to implement security best practices, you can choose the path that aligns with your personal learning goals.

![Learning Paths](https://images.ctfassets.net/23aumh6u8s0i/6QLFAt7aVC12TsgwhULpNC/a797cab358757cac93d4cc1d0453d04b/01_okta-learning-learning-path.png)

## Goal-Oriented Learning Plans

If you're working toward a specific objective—like earning your [Okta Developer - Customer Identity Cloud Certification](https://certification.okta.com/okta-developer-cic-certification-exam)—our [learning plans](https://learning.okta.com/page/development) are designed to guide you through a curated set of activities to support you through your learning journey. These plans provide a clear, structured roadmap so you can stay on track and feel confident in your preparation.

![Goal-Oriented Learning Plans](https://images.ctfassets.net/23aumh6u8s0i/6R0mLRtkwJBecA4e1tdkUt/e03a4607a399e738a9855088243a3b7f/02_okta-learning-learning-plan.png)

## Hands-On Coding Labs and Interactive Learning

We believe in learning by doing. That's why we’ve included interactive activities and [hands-on coding labs](https://learning.okta.com/page/courses-all#delivery-method_hands-on-lab) that allow you to apply what you've learned in a real-world context. From working with Auth0 SDKs to creating custom identity flows you'll gain practical experience to help you build better, more secure applications that fit your requirements.

![Hands-On Coding Labs and Interactive Learning](https://images.ctfassets.net/23aumh6u8s0i/6i3fdO4ksJ2CZNtfsvHCag/2c0f13d7a8d0d0c3b87d1b5932366a79/03_okta-learning-hands-on.png)

## Earn Badges to Showcase Your Skills

To recognize your progress and achievements, we’ve introduced skills-based badging assessments. Successfully pass an assessment, and you'll earn a badge that showcases the skill you've gained—whether it's a foundational understanding of digital identity or an advanced feature of Auth0. [These badges](https://learning.okta.com/page/skill-badges) serve as both a personal accomplishment and a tangible way to demonstrate your expertise to peers, employers, and the broader tech community.

![Earn Badges to Showcase Your Skills](https://images.ctfassets.net/23aumh6u8s0i/EyzFcVcI3qw0tWnhp3ECm/f18010f6fbab2bb40c792eebbe5fdc93/04_okta-learning-skill-badges.png)

## Start Your Learning Journey Today

With Okta Learning, you can take ownership of your own learning journey at your own pace. Whether you’re just starting out in the digital identity space or working towards career advancement, Okta Learning has a path for you.

Get started today and unlock your potential with [Okta Learning](https://learning.okta.com/)!

Knowledge Belongs to You: Introducing the New Okta Learning Experience

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

JWT Profile for OAuth 2.0 Access Tokens with Vittorio Bertocci

## The Overview

In this episode of _Identity, Unlocked_, the CTO and co-founder of Auth0, Matias Woloski, appears as acting host and interviews Vittorio Bertocci, principal architect at Auth0 and the regular host of _Identity, Unlocked_, on the JWT profiles for OAuth2 access tokens specification. 

This spec describes how to encode OAuth2 access tokens in use JWT format in an interoperable way, by giving a minimal list of claims, how to emit a JWT depending on specific aspects of the request, and most importantly, describes how to validate an incoming token based on very specific rules. The document also features sections on security and privacy, highlighting common pitfalls and suggesting ways to prevent and minimize issues.

Vittorio walks Matias through the creation process of this spec, beginning with recognizing that, despite encoding access tokens in JWT was common practice across the industry, there was no guidance on how to do so in any existing standard. After gathering examples of JWT access tokens issued by several different identity products and services, Vittorio presented the general idea for this new spec at the [2019 OAuth Security Workshop](https://osw2019.sec.uni-stuttgart.de/). After receiving interest, he proceeded to produce and propose an internet draft at [IETF104](https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00).

Once the spec was adopted as an official working group item, the workgroup provided an overflow of feedback and the discussions went into much greater and productive detail. While not every interaction in the workgroup is going to be worthwhile or a game changer, Vittorio explains that the working group process is key for producing high quality, widely applicable documents that have been vetted for security and correctness by some of the best experts in the industry. The [specification document ](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12)has now been approved and submitted for IESG publication, one step closer to reaching the status of the official standard.  

Matias and Vittorio speak further about how using this spec JWT profile tokens will make it possible to develop truly interoperable SDKs, allowing developers more time to devote on creating their apps, rather than focusing on low-level implementation differences. Vittorio also hopes this spec will stop the use of ID tokens in place of access tokens, streamline the code required to handle authorization, and help to keep privacy considerations into account when designing API solutions.

The episode closes with a call for action. The work of identity standards groups touches everyone in our industry, but not everyone is represented. Participation is easier than ever, and contributions are welcome - Vittorio encourages reaching out to him for help, extending an invitation to anyone who would like to take part in the process but don’t know where to start.

## Key Takeaways

What is the JWT profile spec, in a nutshell:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c4eb1494"></iframe>

How a spec evolves from an idea:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/226f297c"></iframe>

The JWT profiles for OAuth2 access tokens spec through the workgroup process:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/9a3722e2"></iframe>

Vittorio explains the potential advantages of this JWT spec:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f870c54e"></iframe>

Vittorio’s Call to Action: 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/56147e11"></iframe>

### Links/Resources:

- Connect with Matias Woloski on [LinkedIn](https://www.linkedin.com/in/matiaswoloski/)
- Connect with Matias Woloski on [Twitter](https://twitter.com/woloski)

<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 8

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

Explore how FastFed is looking to shorten the time it takes to join organizations into a federation.

## The Overview

In this episode of _Identity, Unlocked_, principal architect at Auth0 and podcast host Vittorio Bertocci focuses on OpenID foundation’s FastFederation ([FastFed](https://openid.net/wg/fastfed/)) group. Vittorio chats with Darin McAdams, a software engineer at AWS and the author of FastFed’s specifications, to explore how FastFed is looking to shorten the time it takes to join organizations into a federation.

Darin explains that Dick Hardt, one of the founders of FastFed, zeroed in on him to edit and draft the spec for FastFed. Darin began at the beginning, creating a sample G Suite and trying to set up a federation between both AWS and Salesforce. When he finally arrived at a place to begin joining the orgs, he was stuck - the first line, the first page, the needle scratches, and he doesn’t know how to proceed.

Eventually, after reading the SAML specs and following Google’s directions for integration, a long drawn out process of over 40 steps, Darin was finally able to integrate his sample G Suite with AWS, but never Salesforce. It became clear to him this process could be made much faster through automation.

FastFed is going after integrating a push-button single-sign-on experience for users of a federation, and to do so, they have to develop the communication between different authentication programs used by the organizations. FastFed also runs into the complications of communicating between identity providers, enterprise security preferences, and creating trust between the orgs. 

Darin and Vittorio dive into more details of the problems faced creating FastFed and scaling down a program with a vast scope into a push-button user experience.

## Key Takeaways

Darin explains how he discovered the problem FastFed is trying to solve:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/976ce3a6"></iframe>

How FastFed is looking to make the problem better:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/d79c5e15"></iframe>

Darin discusses the logical problems FastFed had to solve:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/1e42983d"></iframe>

SCIM’ing the problem. Funneling the multiple implications of SCIM into a single solution:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/a4e48489"></iframe>

Darin calls on engineers:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/220d2e54"></iframe>


### Links/Resources:

Connect with Darin McAdams on [LinkedIn](https://www.linkedin.com/in/darin-mcadams-3950b52/)<br />
Connect with Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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)<br />
Learn more about [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 6

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host, Vittorio Bertocci, focuses on the Self-Issued OpenID Provider specification, also known as SIOP. We are joined today by Kristina Yasuda, Identity Standards Architect at Microsoft and longtime advocate of decentralized Identity.

## The Overview

Kristina opens by enunciating what SIOP is about, in a nutshell: the ability for an end user to present claims about themselves to a relying party (RP) without the need to redirect to an external provider. The scenario is further clarified through the enumeration of key use cases where that ability is useful, such as circumstances in which an external identity provider might cease to exist (as it actually happened in the earthquake/tsunami disaster that hit Japan ten years ago), or no longer be willing to provide service (as it might be the case in situations where democratic rule is under threat).

The original OpenID Core specification predicted the need for the SIOP, codifying it in [chapter 7](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued). However, at the time, the scenario was largely theoretical; hence the specification leaves out a number of important details - it is those gaps that SIOP is meant to fill. 

One of the most fundamental challenges to solve is the discovery problem, that is to say, the ability of an RP to discover and select a self-issued OP to use to authenticate the user in the current transaction. As a discovery mechanism to invoke a Self-Issued OP, the discussion on the podcast covered the usage of a custom schema 'openid://'. Alternative mechanisms to address the limitations of custom schemas are being actively explored in the WG.

The conversation meanders through deeper details, from how the current [SIOP specification draft](https://bitbucket.org/openid/connect/src/master/openid-connect-self-issued-v2-1_0.md) under the OpenID Foundation picks up the mission from a [former attempt under DIF](https://identity.foundation/did-siop/) to encoding approaches for verifiable presentations (embedding in JWTs, [LD proofs](https://w3c-ccg.github.io/ld-proofs/)), how to represent attributes (with a mention of [eKYC](https://openid.net/wg/ekyc-ida/), which we covered in an [earlier episode of the show](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/ad784008)).

As a final thought, Kristina relays that a lot of the work that took place so far in this space aimed at developing data models- and that it's time to flesh out the transport, the protocol aspect of the scenarios.

In closing: the ideal call to action from all this is to implement the specs and give concrete feedback - and if the episode helped clarify the aim and the scenarios SIOP targets, to help spread that clarity and demystify the topic for others!

## Key Takeaways 

**[3:25]** - What is SIOP?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/d430a348"></iframe> <br /> 

**[7:27]** - Mechanisms to leverage the relationship between OpenID provider and user. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c71f9f9b"></iframe> <br />

**[8:52]** - A look at the original Chapter 7 of OpenID Connect. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/8917d786"></iframe> <br />

**[11:10]** - Planned revisions for Chapter 7 of OpenID Connect. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/21da8dad"></iframe> <br />

**[13:35]** - On what platform do these DIDs live? 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/9bdabf19"></iframe> <br />

**[20:28]** - What is the current status of SIOP?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/9d50331f"></iframe> <br />

**[25:00]** - Vittorio’s summary of the episode. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/7b823cd4"></iframe> <br />

**[27:00]** - Kristina’s call to action for listeners. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f9f56d8c"></iframe> <br />

### Links/Resources:

OIDF SIOP draft [here](https://bitbucket.org/openid/connect/src/master/openid-connect-self-issued-v2-1_0.md)<br />
Old DIF SIOP draft [here](https://identity.foundation/did-siop/)<br />
LD proofs [here](https://w3c-ccg.github.io/ld-proofs/)<br />

Learn more about [JWK thumbprints](https://connect2id.com/products/nimbus-jose-jwt/examples/jwk-thumbprints)<br />
Learn more about [Kristina Yasuda](https://www.linkedin.com/in/kristina-yasuda-6263b5a2?originalSubdomain=jp) <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 />

## About OpenID Foundation

The OpenID Foundation is a non-profit international standardization organization of individuals and companies committed to enabling, promoting, and protecting OpenID technologies. Formed in June 2007, the foundation serves as a public trust organization representing the open community of developers, vendors, and users. OIDF assists the community by providing needed infrastructure and helps in promoting and supporting the expanded adoption of OpenID. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID.

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />

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



## The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com/) and podcast host, Vittorio Bertocci, invites guest Filip Skokan to have a conversation about a few three-letter extensions to OAuth (which, incidentally, would also fit well in a pirate incantation!): PAR, RAR, and JAR. Filip is a Senior Engineer II at Auth0, the author of a popular book on open source identification, and a contributor to both the [IETF](https://www.ietf.org/) and the [OpenID Foundation](https://openid.net/foundation/).

Before getting into the three extensions, Vittorio asks Filip to share his background in Identity. In 2013, Filip moved to Germany to work for a games publishing company; more specifically, he helped maintain the company’s single sign-on protocol. He was eventually assigned to a special project, and through the process of completing it, he became engrossed in what [OpenID Connect](https://openid.net/connect/) had to offer and started working on his own [OpenID](https://openid.net/) authorization server. He stumbled onto OpenID Connect’s [certification](https://openid.net/certification/) program, learned about defense specifications through his involvement with a team managing certification software, and - through the blur of a rapidly developing career - next recalls speaking at a conference in Chicago. His work on open source projects put him on the radar of Auth0, and he was recruited to join the company. Now, supported by Auth0 and based in the Czech Republic, he continues to contribute to various groups, such as the OpenID Foundation and OAuth, and to feed information on new developments back to Auth0. 

Turning to the three acronyms Vittorio wants to discuss, Filip clarifies what they are and what problems they solve. All three of the acronyms deal with shortcomings in the core OAuth specifications. They are extensions developed to meet changing user needs as [OAuth 2](https://oauth.net/2/) has been applied in many different ways. [RAR](https://oauth.net/2/rich-authorization-requests/), or rich authorization request, is a framework that originated in the [FAPI](https://openid.net/wg/fapi/) working group and that brings more expressive power to authorization requests. [JAR](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/jar), or JWT-secured authorization request, originally came from OpenID Connect and allowed requests to be integrity-protected by making them JWTs. [PAR](https://oauth.net/2/pushed-authorization-requests/), or pushed authorization request, deals with the dilemma of excessively large URLs, turning authorization into a server-to-server call by introducing a pushed authorization endpoint to the authorization server. Vittorio and Filip explain each extension, and while all three extensions are still in the draft stage, Filip shares where each is in the process of standardization for common use.  

## Key Takeaways 

**[06:33]** - What do the three acronyms describe, and what problems do they solve?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/0d0c0c78"></iframe>

**[07:52]** - What is RAR and what is its contribution of expressive power to requests?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/21d8541a"></iframe>

**[10:53]** - Vittorio asks about JAR, and Filip shares about its way of using JWTs in transmission.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/113a130f"></iframe>

**[12:18]** - PAR is next, and it deals with excessively large URLs using pushed authorization endpoints.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/0fd2d9db"></iframe>

**[15:03]** - PAR has other side effects, as well.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/a5c3d3ff"></iframe>

**[16:31]** - Vittorio requests more detail on an outworking of PAR.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/1a19d87e"></iframe>

**[18:55]** - Vittorio asks where the three extensions are in the standardization process.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/403f6e3e"></iframe>

### Links/Resources:

Learn more about [Filip Skokan](https://auth0.com/blog/authors/filip-skokan/) and connect with him on [Twitter](https://twitter.com/_panva?lang=en)<br />
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)<br />
Learn more about [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. 2



## The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com/) and podcast host, Vittorio Bertocci, focuses on the work of the eKYC and Identity Assurance Working Group in the [OpenID Foundation](https://openid.net/foundation/). In order to explore the group and its work, Vittorio interviews Mark Haine, Director at [considrd.consulting](https://www.considrd.consulting/), and one of the Chairs of the [eKYC and Identity Assurance Working Group](https://openid.net/wg/ekyc-ida/).

The working group is named for two processes that are largely the same but represent different industries. eKYC or Electronic Know Your Customer is a process most closely tied to the financial industry, whereas identity assurance is the more generic counterpart present in most other sectors. Identity assurance is the process of establishing the Identity of someone you’re interacting with within a very reliable fashion, and while it was historically often carried out in person, the rapid transition to new technologies and options for remote engagement - all prompted by the COVID-19 pandemic - have created a need to find ways of moving identity assurance online and allowing for it to be done in a standardized fashion.

The working group [charter](https://openid.net/wg/ekyc-ida/charter/), in summary, explains the group’s aim to deliver a tech solution that communicates verified claims and information about how they were verified. The information to be communicated is metadata about claims, answering questions of how and when claims were established. The working group represents many countries and industries and was launched in the context of the OpenID Foundation because of the natural connections between the foundation and the group’s initiative. Offering further detail on this project, Mark comments on the choice not to mandate but only to encourage the use of FAPI, level of adoption of the working group’s spec thus far, and - with regard to deliverables - what specification documents and definitions the group is working with. As the conversation winds to a close, Mark explains the danger of using scope, the TXN claim within the working group’s program, the PKI analogy for program service, and ways listeners can help by fostering awareness of the program and its many less obvious use cases.

## Key Takeaways 

**[4:04]** - Mark talks about the eKYC acronym, identity assurance, and standardization.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/6db73961"></iframe>


**[7:13]** - Mark summarizes the working group charter.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/03134982"></iframe>


**[9:28]** - The working group is international and naturally connects to the OpenID Foundation.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/60ac944f"></iframe>


**[15:51]** - Vittorio asks about program deliverables, focusing on specifications documents.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f4de3dc8"></iframe>


**[20:53]** - He asks about the TXN claim within the program, service arrangements, and more.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/1ef96c6e"></iframe>


**[24:23]** - If Mark issued a to action, it would center on awareness.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/6d9660e9"></iframe>

### Links/Resources:

Learn more about [Mark Haine](https://www.linkedin.com/in/mark-haine/?originalSubdomain=uk) and the [eKYC and Identity Assurance Working Group](https://openid.net/wg/ekyc-ida/). <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 />

## About OpenID Foundation

The OpenID Foundation is a non-profit international standardization organization of individuals and companies committed to enabling, promoting, and protecting OpenID technologies. Formed in June 2007, the foundation serves as a public trust organization representing the open community of developers, vendors, and users. OIDF assists the community by providing needed infrastructure and helps in promoting and supporting the expanded adoption of OpenID. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID.

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


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

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

Torsten Lodderstedt joins the podcast today to talk about his work on Financial-Grade API (FAPI) WG.



## The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host, Vittorio Bertocci, interviews Torsten Lodderstedt. Torsten is the CTO of [yes.com](https://yes.com/) and is an all-star contributor to the [IETF](https://www.ietf.org/) and the [OpenID Foundation](https://openid.net/foundation/). The interview centers on Torsten’s work on [Financial-Grade API (FAPI) WG](https://openid.net/wg/fapi/).

FAPI is a security and interoperability profile for OAuth, and it was originally intended for use in open banking scenarios. Torsten explains how FAPI navigates two challenge areas of using OAuth in open banking, what one may find within the FAPI working group initiatives, and the differences between FAPI versions 1 and 2. Further, Torsten delves into some specific macro areas of FAPI and discusses [JARM (JWT Secured Authorization Response Mode)](https://bitbucket.org/openid/fapi/src/master/Financial_API_JWT_Secured_Authorization_Response_Mode.md). He details cryptography measures such as MTLS and their relation to FAPI, his thoughts on the future of FAPI, prominent features in the specifications (such as CIBA, or Client Initiated Backchannel Authentication), and helps listeners interested in FAPI to determine what version might best suit them. Of course, if listeners have to integrate with another system, then they must see what that system can support. But for the listener who owns their own API, Torsten’s general recommendation is to consider FAPI version 2!

To learn more about the FAPI working group, how to participate, and information about the specification, visit [https://openid.net/wg/fapi](https://openid.net/wg/fapi)

To learn more about OpenID Foundation’s Global Open Banking initiatives, visit [https://fapi.openid.net](https://fapi.openid.net)

## Key Takeaways

**[6:05]** - What is FAPI?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/6308d351"></iframe>

The main entry point for all things FAPI can be found at [https://openid.net/wg/fapi/](https://openid.net/wg/fapi/)
<br />
**[9:56]** - What can be found inside FAPI?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c4ab14b1"></iframe> 
<br />
**[12:11]** - What is a detached signature?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/89529a00"></iframe> 

The JWT secured authorization request Torsten mentions can be found in [https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30](https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30). 
<br />
**[14:48]** - What specification areas are defined in FAPI 1.0?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/7b18b29b"></iframe> 

The specifications Torsten mentions can be accessed here:

* [FAPI 1.0 — Part 1: Baseline API Security Profile (Draft towards the final specification).](https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md)
* [FAPI 1.0 — Part 2: Advanced Security Profile (Draft towards the final specification).](https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md)
* [FAPI 1.0 — JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) (Implementer’s Draft).](https://bitbucket.org/openid/fapi/src/master/Financial_API_JWT_Secured_Authorization_Response_Mode.md)
* [FAPI 1.0 — CIBA Profile (Implementers Draft).](https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md)
<br />
**[20:08]** - Discussion about other security measures and their relation to FAPI.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/ac6c32e9"></iframe> 

MTLS and DPoP, mentioned by Torsten in this context, have been covered in Identity, Unlocked Season 1, Episode 1, available [here](https://auth0.com/blog/identity-unlocked-explained-episode-1/).
<br />
**[23:07]** - The Future of FAPI and MTLS.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/2967c283"></iframe> 
<br />
**[25:12]** - The third component of FAPI: CIBA
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f40ce0a3"></iframe> 
<br />
**[31:25]** - FAPI 2.0
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/16c62c56"></iframe> 
<br />
**[37:28]** - Implementing FAPI 1.0 and FAPI 2.0
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f260f5b6"></iframe> 
<br />
**[41:07]** - About the OpenID Foundation
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/46196332"></iframe> 
<br />

## About OpenID Foundation

The OpenID Foundation is a non-profit international standardization organization of individuals and companies committed to enabling, promoting and protecting OpenID technologies. Formed in June 2007, the foundation serves as a public trust organization representing the open community of developers, vendors, and users. OIDF assists the community by providing needed infrastructure and help in promoting and supporting expanded adoption of OpenID. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID.

### Links/Resources:

Learn more about [Torsten Lodderstedt](https://www.linkedin.com/in/torsten-lodderstedt-37528a1/) and follow him on [Twitter](https://twitter.com/tlodderstedt)<br />
Connect with Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/) and follow him on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [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. 1

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

Highly-rated identity specifications and trends podcast concludes season one; season two to launch in January 2021



**BELLEVUE, Wash. – Dec. 17, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that the [OpenID Foundation](https://openid.net/foundation/) will be the exclusive sponsor for season two of Auth0's flagship podcast ['Identity, Unlocked,'](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/025d70b9?utm_source=podcast&utm_medium=pr&utm_campaign=identity-unlocked) scheduled to release in January 2021. Auth0 and the OpenID Foundation will bring their shared goals around promoting awareness, understanding, and adoption of open identity standards to the podcast in an effort to make identity more accessible.

Hosted by Vittorio Bertocci, identity expert and principal architect at Auth0, 'Identity, Unlocked' features conversations with identity thought leaders and explores the latest specifications and trends from a developer's perspective, making identity more accessible to everyone. [Season one](https://auth0.com/blog/auth0-launches-identity-unlocked-the-identity-podcast-for-developers/) recently concluded and featured interviews with industry standards experts and identity thought leaders, including Brian Campbell, Dick Hardt, Pamela Dingle, and many others. 

Season two of 'Identity, Unlocked' will explore OpenID Connect specifications such as Financial-grade API (FAPI), Self-issued OpenID Connect (SIOP), and eKYC and Identity Assurance (IDA) to compliment the show's history of interviewing those directly involved in the creation of identity standards. In addition to the OpenID Connect specifications, 'Identity, Unlocked' will continue to explore various specifications and trends across the identity industry.

"Our hope is that the OpenID Foundation's sponsorship of the Auth0' Identity Unlocked' podcast will encourage further deep and diverse technical contributions to the open identity standards the Foundation has developed," said Don Thibeau, OpenID Foundation Executive Director. "This podcast will continue to educate and introduce a global community of contributors to working groups like the Financial-grade API (FAPI), eKYC-IDA, and others. The deep dive into these technologies on 'Identity Unlocked' is a priority for the OpenID Foundation and a unique resource for open standards development in 2021."

"Thank you to everyone involved in 'Identity, Unlocked' season one—we are grateful for the positive response we received during season one, and we look forward to collaborating on the second season in partnership with OpenID Foundation," said Martin Gontovnikas, SVP of Marketing and Growth at Auth0. "Open identity standards are of critical importance, and it is our goal to make identity more accessible to everyone, in an inclusive way."

To learn more about 'Identity, Unlocked,' visit [identityunlocked.com](http://identityunlocked.com/). To subscribe to the latest podcast updates and episodes, visit [Apple Podcasts](https://podcasts.apple.com/us/podcast/identity-unlocked/id1529010471) and [Spotify](https://open.spotify.com/show/1Y6XBZcVK45QijvV0o7RVs). 

## About Vittorio Bertocci

[Vittorio Bertocci](https://auth0.com/blog/authors/vittorio-bertocci/) is Principal Architect at Auth0 and applies his vast knowledge of the identity industry to Auth0 in all aspects of the company, including internal and external education, product innovation, and customer integration. Prior to Auth0, Bertocci spent 17 years at Microsoft, where he worked on the Azure Active Directory team and focused largely on improving the developer experience. As a published author of four identity books and a highly-trafficked blog: cloudidentity.com, his forward-thinking commentary has enabled him to speak at conferences, such as Identiverse, BUILD, PDC, TechEd, Cloud Identity Summit, and many other industry events around the world.

<include src="asides/AboutAuth0" />

### Media Contacts
Auth0 Global Communications <br />
[press@auth0.com](mailto:press@auth0.com) <br />
 
Matter for Auth0  <br />
[auth0@matternow.com](mailto:auth0@matternow.com)  <br />


OpenID Foundation to Sponsor Auth0's Identity, Unlocked Podcast

SignIn.org and the genesis of the GNAP working group



## The Overview

In this episode of _Identity, Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host Vittorio Bertocci interviews Dick Hardt. Dick is the founder of SignIn.org, and he and Vittorio discuss the genesis and goals of a new IETF working group Dick helped to establish and served as chair until June 2020- the [Grant Negotiation and Authorization Protocol (GNAP)](https://datatracker.ietf.org/wg/gnap/documents/).

As the conversation begins, Dick overviews his background as a mechanical engineer moving into and working within the field of identity, highlights how he maneuvered ahead of the tech curve throughout his career, brings listeners to the current moment and his work to solve internet identification with SignIn.org, and talks about meeting Vittorio. Moving forward, he and Vittorio jump right into their discussion of GNAP, with Vittorio asking what it is and what problem it aims to solve. 

Vittorio also wants to explore how GNAP was developed, and Dick explains how a [Birds of a Feather](https://www.ietf.org/how/bofs/) working group was formed, a community and interest were built, and a mailing list and meeting were planned. The decision was made to create a new group apart from OAuth, and Dick clarifies that the GNAP working group does not feel constrained by existing technology; GNAP does not need to be backward-compatible, but Dick still hopes that the transition to GNAP will be smooth for those who use it. Further, Dick explains the two drafts behind GNAP, which together form the basis for going forward.[**IMPORTANT**: the episode was recorded in August 2020. Earlier this month (November 2020), the GNAP working group adopted one draft. You can find it on the working group’s documents page at [https://datatracker.ietf.org/wg/gnap/documents/](https://datatracker.ietf.org/wg/gnap/documents/)]. He then goes into detail, addressing his work on consumer identification at SignIn.org and the way in which GNAP might enable smooth functioning of SignIn.org’s program. Vittorio and Dick explore the significance of SignIn.org’s browser-based model, the interaction element of GNAP, and more!

## Key Takeaways:

**[7:37]** - What is GNAP and what problem does it solve?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/13ce1925"></iframe>  <br />

**[11:54]** - What are the main issues in OAuth2, and what is the general idea of GNAP?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/be1753a1"></iframe>  <br />

**[17:16]** - How was the working group formed?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/739afe61"></iframe>  <br />

**[26:27]** - What is SignIn.org?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/3a1af4df"></iframe>  <br />

**[33:20]** - There is interaction within GNAP.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/3a1af4df"></iframe>  <br />


## Links/Resources: 

Learn more about [Dick Hardt](https://www.linkedin.com/in/dickhardt/) and follow him on [Twitter](https://www.ietf.org/how/bofs/)  <br />
Learn more about [SignIn.org](https://signin.org/)  <br />

Learn more about [GNAP](https://datatracker.ietf.org/wg/gnap/documents/)  <br />
Learn more about [OAuth](https://oauth.net/)  <br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked...Explained | Episode 6

John Bradley joins the podcast today to talk about identity management specs, including FIDO2



## The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host, Vittorio Bertocci, has a conversation with John Bradley. John is the Senior Standard Architect at [Yubico](https://www.yubico.com) and the author of many important specifications pertaining to identity management, including FIDO2. 

As usual, Vittorio begins the interview by asking John how he got into the field of Identity. John overviews his career and when he met Vittorio before turning to his current work on web authorization and FIDO2 standards. John’s current company is Yubico, and in his role with the organization, John wrangles standards. In other words, he represents Yubico at standards organizations and plays referee between companies in order to make sure the entire community is benefited by the companies’ shared work. Moving forward, Vittorio asks John to clarify significant terms for listeners. In order to do so, John shares the story of how Yubico and Google worked on their own program, U2F (Universal Second Factor) authentication, as other companies independently started FIDO. Yubico and Google decided to join FIDO in order to not be seen as competing, and the merged organization joined and developed technology to produce FIDO2. John further clarifies that FIDO2 is a marketing term rather than an actual standard, and the standards at play are WebAuthn and CTAP (Client to Authentication Protocol).

Vittorio and John also discuss details about how this technology works, with Vittorio boiling the ideas down to a description of a browser using CTAP to communicate with an authenticator, who then uses WebAuthn to communicate with a website. On the back end, the FIDO infrastructure is one of the various options for server validation. At this point, John clarifies, he and his team see WebAuthn used more as a second factor for authentication than as the first factor; however, with Apple’s work on multi-factor authentication, John imagines that the pattern of WebAuthn use may change. John expects that people will probably use local face or touch identification for the web credential for individual devices. Once this technology becomes ubiquitous, passwords will become increasingly obsolete. Of course, there are still problems that this vision of the future raises, and John and Vittorio talk through some of these problems, the need for the industry to create new practices, and ways in which authentication will likely become more integrated into our lives (as we’ve seen it start to do in the form of such things as wearable authenticators). As the conversation moves toward a conclusion, Vittorio asks John to share about what his team is working on now and plans to work on in the days ahead, including level 2 of WebAuthn, CTAP 2.1, and much more!

## Key Takeaways

**[4:20]** - John clarifies the history of FIDO and FIDO2
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/07ba0635"></iframe>

**[6:13]** - John explains the history of WebAuthn
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/3215c0e1"></iframe>

**[10:59]** - Uses of WebAuthn
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/16f4f646"></iframe>

**[14:57]** - How do you recover passwords without a roaming authenticator?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/66785f49"></iframe> 

**[18:26]** - Has John ever considered an idea like implants for authentication?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/b871ac90"></iframe>

**[21:45]** - John explains his work in progress and what he sees on the horizon.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/fbaf654a"></iframe>
<br />

### Links/Resources:

Learn more about [John Bradley](https://www.linkedin.com/in/ve7jtb/?originalSubdomain=cl) <br />
Follow [John Bradley on Twitter](https://twitter.com/ve7jtb) <br />
Learn more about [Yubico](https://www.yubico.com/) <br />
Learn more about [FIDO2](https://fidoalliance.org/fido2/) <br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="WebAuthnMeCTA" group="B"/>

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked...Explained | Episode 5

Daniel Fett joins the podcast today to talk about the security BCP document.



## The Overview

On the fourth episode of _Identity, Unlocked_, host Vittorio Bertocci, principal architect at [Auth0](https://auth0.com/), is joined by Daniel Fett, a security specialist at yes.com. Daniel received his Ph.D. from the University of Stuttgart through research on the formal analysis of web protocols. Daniel joins the podcast today to talk about the security BCP document. 

A BCP document is a document that describes the best current practices for any given field. Fett is a co-author and has been working on the [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16) document. This document gives an update on the best industry practices, but it does not override the core specifications. Instead, this document provides additional information and practices in OAuth. While there are many great recommendations in this document, three of the most important that stand out to Daniel are:

1. Recommendations to not use the implicit grant any longer.
2. If the authorization code grant is used, PKCE should also be used.
3. Use sender constraining for the access tokens when possible, or at least have rotation for the refresh tokens.

The implicit grant is the process where an authorization server creates the access token and sends it to the browser that requested the access token. Although this is beneficial from a usability standpoint, there are several problems from a security perspective. Daniel unpacks several of the security concerns of implicit flow. Next, he and Vittorio discuss using PKCE when using the authorization code grant. PKCE helps to combat a mix-up attack. This type of attack is called a code injection attack, where attackers gain access to a confidential access code. With PKCE, the client for each run will invent a new code challenge or code verifier and will only accept a code that is bound to the same code challenge. This means that if an attacker tries to inject another code, it will not be bound to the correct code challenge. Finally, Daniel explains the BCP recommendations around sender constraint. He recommends using sender constraint for access tokens whenever possible. 

## Key Takeaways:

**[4:20]** - What is a BCP document, and how is it different from the core specification?
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/23714281?clip=684211d2&embed=true"></iframe> 

**[6:48]** - What are the top three most impactful recommendations in the BCP?
Here’s the list of direct links to the top three spec recommendations Daniel mentions

* Don’t use the [implicit grant](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.1.2) to get access tokens
* [Use PKCE for every code authorization flow](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.1.1), regardless of client type
* [Sender constraint for access tokens and/or refresh token rotation](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2)
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/23714281?clip=c09b4490&embed=true"></iframe> 

**[7:59]** - What are the problems with the implicit grant?
The problems with the implicit grant have been explored in the podcast [episode about OAuth2.1 with Aaron Parecki](https://auth0.com/blog/identity-unlocked-explained-episode-2/), last section - and we expanded on the issues further in [this post](https://auth0.com/blog/oauth2-implicit-grant-and-spa/). Check those out if you want to dig deeper!
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/23714281?clip=f39ed326&embed=true"></iframe> 

**[16:02]** - Using authorization code grant when using PKCE. 
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/23714281?clip=b4930d9d&embed=true"></iframe> 

**[26:09]** - What are the BCP recommendations around sender constraint?
This is a topic we explored in-depth with Brian on the podcast’s inaugural episode- you can find the audio and associated explanations [here](https://auth0.com/blog/identity-unlocked-explained-episode-1/).
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/23714281?clip=59a3e3d9&embed=true"></iframe> 

### Links/Resources:

Learn more about [Daniel Fett](https://danielfett.de/)<br />
Visit [yes.com](https://yes.com/)

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked...Explained | Episode 4

Pamela Dingle joins the show to discuss how standard organizations operate, and how the industry is evolving.



## The Overview

In this episode of Identity, Unlocked, host Vittorio Bertocci, principal architect at Auth0, is joined by Pamela Dingle, Director of Identity Standards at Microsoft and a founding member of Women in Identity. Pamela has been working with identity standards and related organizations for a long time: in this episode, she sheds light on the fundamental value proposition of open standards, how standard organizations operate, and how the industry is evolving. 

Standards are the main mechanism through which we harness collective intelligence and avoid continuously reinventing the wheel, as Pamela masterfully states before launching in a historical review of how the world of identity standards evolved. Starting with cornerstone standards such as LDAP and SAML, and associated standard bodies such as the Liberty Alliance, Pamela and Vittorio reminisce about a time in which only large companies had a say on industry standard’s direction. The discussion quickly branches out, moving toward organizations such as IETF and the OpenID Foundation responsible for the main modern standards (such as the OAuth 2.0 and OpenID Connect families of specs) we work with today. Throughout the chat, Pamela provides her perspective on concrete aspects of working on standards such as driving consensus while being inclusive of diverse perspectives, the fine balance between extensibility and strict guidance every standard strives towards, and more.

As the episode ends, Pamela discusses Women in Identity, where she serves as a director. Women in Identity is a non-profit organization creating identity solutions for and built by everyone. They’re working to drive a more diverse workforce in the digital identity industry. Their membership is open to women and their allies. 

## Highlights 

**[3:55]** - What are identity standards? 

The cast of characters mentioned here includes Anthony Nadalin ([@drsecure](https://twitter.com/drsecure)), Dale Olds ([@daleolds](https://twitter.com/daleolds)), and Mark Wahl ([@markwahl](https://twitter.com/markwahl)).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0308906d&embed=true"></iframe> 


**[6:12]** - How did identity standards come into practice? 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=73d0ab82&embed=true"></iframe> 


**[7:37]** - What is LDAP?

You can find more details about LDAP [here](https://tools.ietf.org/html/rfc4510), but nowadays, chances are you won’t run into any situation requiring you to know so much about it.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0147dbc8&embed=true"></iframe> 


**[16:05]** - What is IETF? 

The IETF site, at [https://www.ietf.org/](https://www.ietf.org/), reflects the incredible breadth of the organization’s scope, which concerns itself with all things internet hence goes well beyond Identity. All the OAuth related activity (specs, smiling list traffic, etc.) can be found at [https://datatracker.ietf.org/wg/oauth/about/](https://datatracker.ietf.org/wg/oauth/about/).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0cd38fe6&embed=true"></iframe> 


**[20:37]** What is the OpenID foundation?

The OpenID foundation can be found at [https://openid.net/foundation/](https://openid.net/foundation/). If you want to go straight to the specs, you’ll find them on [https://openid.net/developers/specs/](https://openid.net/developers/specs/).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/2475502a"></iframe> 


**[32:50]** - What is Women in Identity? 

Women in Identity’s home page is on [https://womeninidentity.org/](https://womeninidentity.org/) - you can follow them on twitter at [https://twitter.com/WomeninID](https://twitter.com/WomeninID).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0cd38fe6&embed=true"></iframe> 

## Links/Resources

Learn more about [Pamela Dingle](https://www.linkedin.com/in/pameladingle/)<br />
Learn more about [Women in Identity](https://womeninidentity.org/)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 3

Aaron Parecki joins the show to discuss the development of the OAuth 2.1 specification.



### The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host, Vittorio Bertocci, speaks with Aaron Parecki. Aaron is currently senior security architect at [Okta](https://developer.okta.com/), and he has spent much of his career focusing on [OAuth](https://oauth.net/). He writes and teaches on the subject and joins Vittorio to discuss the latest project he's been working on: the development of the OAuth 2.1 specification.

OAuth 2.1 is a revision of the OAuth 2 core specification and involves a dramatic reduction in the amount of reading that identity providers and SDK authors need to get up to speed on OAuth. The project aims to consolidate current material on OAuth, offering a guide to best practices and including the most relevant guidance directly in the core specification.

Moving into more of the details of the project, Vittorio first asks what OAuth2.1 adds to the OAuth 2 core.
One major addition is the requirement to use PKCE in every authorization grant, including the cases involving confidential clients. 
Recommendations for browser-based apps are in the works, and the new guide will include some stricter requirements defined in the security best current practices document, such as restrictions around refresh tokens. OAuth 2.1 will also introduce a new term, "credentialed client," defined as a client that has credentials but no confirmed identity. The concept already exists in OAuth 2, OAuth 2.1 simply gives it a name so that it can be treated as a legitimate client type, along with the classic public and confidential.
Aaron also explains that OAuth 2.1 omits any mention of implicit flow and password grants, and he and Vittorio finish the conversation with a deep dive on the differences between id tokens and access tokens.

### Highlights

**[5:59]** - Vittorio asks Aaron about OAuth 2.1.

As mentioned during the discussions, [OAuth 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00) (currently in [draft 00](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00))consolidates a number of different specifications. Here's the current list:

* [OAuth 2.0 Core (RFC6749)](https://tools.ietf.org/html/rfc6749)
* [OAuth 2 Bearer Token Usage (RFC6750)](https://tools.ietf.org/html/rfc6750)
* [Proof Key for Code Exchange by OAuth Public Clients (RFC7636)](https://tools.ietf.org/html/rfc7636)
* [OAuth2 Security BCP (draft 15)](https://www.ietf.org/id/draft-ietf-oauth-security-topics-15.html)
* [OAuth2 for Native Apps (RFC8252)](https://tools.ietf.org/html/rfc8252)
* [OAuth2 for Browser-Based Apps BCP (draft 6)](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-06)

By providing a single document with the best & more relevant sections of all those specifications, developers building identity tools, authorization server products, and SDKs will have a much easier time finding the most up to date guidance on how to implement delegated authorization in their scenarios. 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=89b892de&embed=true"></iframe> 

**[11:00]** - Addressing the main additions to the OAuth 2 core, Aaron first talks about the main new requirement introduced by OAuth2.1: imposing the use of PKCE for every authorization grant, regardless of the client type. 

The PKCE requirements is currently introduced in [section 4.1.1 of OAuth 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-4.1.1) (location likely to change as the spec structure evolves). We don't go in the details of PKCE here, as we'll cover the topic more in-depth in an upcoming episode this season (the one about the OAuth2 security BCP, with Daniel Fett); however, if you are interested in the details of the code injection attack, Aaron mentions, please check out [this video](https://www.youtube.com/watch?v=1ot45WwQWJE).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=baa5b4f0&embed=true"></iframe> 

**[14:30]** - Besides PKCE, what is being added to the core?

You can find a good backgrounder on refresh token rotation in [this post](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/). 
The podcast episode discussing sender constraint, MTLS and DPoP can be found [here](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=9ab6f037&embed=true"></iframe> 

**[20:48]** - Vittorio and Aaron turn to credentialed clients, the new term defined in OAuth 2.1.

Credentialed clients are defined in [Section 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-2.1) of the current draft of the OAuth 2.1 specification.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=bfe41a40&embed=true"></iframe> 

**[25:55]** - What has been removed from the core? 

The arguments for not including in OAuth 2.1 the resource owner password grant (ROPG) are well known; hence there isn't much to add or explain on top of what we say on the podcast.

The implicit discussion is a bit more nuanced. You can find a more in-depth discussion in this post from a while back- but there's no doubt about its omission from OAuth 2.1 being a good move. The detail that is perhaps worth expanding on is how the considerations that led to omitting the implicit flow from OAuth 2.1 don't really impact the use of implicit + form POST to get an id token in OpenID Connect for web sign-on in traditional web apps.

In a nutshell: OAuth 2 introduced the implicit flow as a way of getting access tokens, the only token type it defines, directly from the authorization endpoint- and mostly with single-page apps in mind. As we have seen in the podcast episode on sender constraint, leaking access tokens meant to be used as bearer tokens has serious consequences, as attackers can successfully reuse leaked tokens. If you consider the fact that returning access tokens via implicit flow for single-page apps specifically creates more attack surface for stealing tokens (token bits in referral headers, browser history, etc.), you can see how it's prudent to fall back on more robust methods, such as authorization code with PKCE directly in JavaScript.

None of the above really applies to get id tokens via implicit + form post when implementing web sign-on in OpenID Connect That's for two main reasons, as identified in the podcast discussion:

1. The mechanics of returning a token via form post are more robust than the ones using a fragment. Tokens returned via form post don't end up in referral headers or the browser history as query elements do.
2. More importantly: OpenID Connect implements measures that make it hard to reuse a leaked id token, for example, by using a nonce.

To better understand the last point, take a look at the following diagram.

![Diagram Token](https://images.ctfassets.net/23aumh6u8s0i/5JM77M913ht4ohtWiulli4/091cff95c794b0b13f30a3dc6c83b725/diagram-token)

When a web app wants to perform a sign in with an OpenID Connect provider, it generates a nonce (random unguessable string), it saves the value of the nonce so that it can be retrieved in the context of the current transaction (for example, by asking the browser to save a cookie containing the nonce value and somehow protected from tampering, for example by signing the cookie with a secret) and it includes the nonce in its sign-in request.

Leg 1 in the diagram shows the step right after all that occurs, with the sign-in request including the nonce reaches the authorization server acting as OpenID Connect provider.  
Upon successful authentication, the provider returns an id token that, besides being signed (not shown in the diagram), featuring the canonical claims, etc. etc., also includes a nonce claim carrying the nonce value received during the sign-in request.

In the form post case, the browser reacts as shown in leg 3- by immediately POSTing a form containing the id token to the requesting app, along with the nonce cookie created at request time.
Upon receiving the id token, the web app validates it as established by the OpenID Connect spec, and, as part of its validation checks, it verifies that the nonce claim value corresponds to the nonce saved in the tamper-proof cookie. If the values do match, the web app considers the request valid- and, as shown in leg 4 of the diagram, establishes a session of its own and, importantly, removes the nonce tracking cookie (or any other measure that would make the nonce single use).

If an attacker manages to steal the id token and attempts to use it, they will be unable to present a corresponding nonce tracking cookie with the value matching the id token content- as they don't have access to the crypto material the web app uses to manufacture and verify such cookies. Voila, the replay attack is defeated! 

Although this is not directly germane to OAuth 2.1 per se, you can expect discussions like above to be common in the months ahead as the community digests the impact of the changes in OAuth 2.1. Hopefully, this diagram, and this podcast episode in general, equipped you to contribute to those discussions and decide how to apply this knowledge to your own scenarios!

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=714b5bc0&embed=true"></iframe> 

If you want to dig further on the topic of OAuth 2.1, you can also take a look at the recording of a 30 mins session from the ASC 2020 conference [here](https://www.youtube.com/watch?v=tEUIsc6skJQ).

### Links/Resources:

Learn more about [Aaron Parecki](https://aaronparecki.com/)<br />

Aaron Parecki on [Twitter](https://twitter.com/aaronpk)<br />
Aaron’s ebook on [OAuth](https://oauth2simplified.com/)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 2

Host Vittorio Bertocci and identity thought leaders make identity specifications and trends more accessible



**BELLEVUE, Wash. – Sept. 17, 2020** – The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of ‘[Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/025d70b9?utm_source=podcast&utm_medium=pr&utm_campaign=identity-unlocked)’, a new podcast featuring conversations with identity thought leaders. Hosted by Vittorio Bertocci, identity expert and principal architect at Auth0, the podcast explores the latest specifications and trends from a developer’s perspective, making identity more accessible to everyone.

[Season one](https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/) of ‘Identity, Unlocked’ features interviews with industry standards experts and identity thought leaders, including:

* **[Now available](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?utm_source=podcast&utm_medium=pr&utm_campaign=identity-unlocked):** OAuth2 Sender Constraint Support: DPOP and MTLS with Brian Campbell
* **September 28:** What's New with OAuth2.1 with Aaron Parecki
* **October 12:** The Importance of Identity Standards with Pamela Dingle
* **October 26:** A Lap Around the OAuth2 Security BCP with Daniel Fett
* **November 9:** WebAuthN and FIDO2 with John Bradley
* **November 23:** Breaking New Ground: The GNAP Working Group with Dick Hardt

“‘Identity, Unlocked’ bridges the gap between ultra-specialized specification talk and practical applications, making identity more accessible to everyone,” said Bertocci. “From a wide range of topics that go from the immediately consequential such as OAuth2 security BCP and OAuth2.1 to the future looking like GNAP, each episode features a fun and informative chat among identity friends, discussed in a format that never loses sight of the concrete development applications.” 

To learn more about ‘Identity, Unlocked’, visit [identityunlocked.com](http://identityunlocked.com/). To subscribe to the latest podcast updates and episodes, visit [Apple Podcasts](https://podcasts.apple.com/us/podcast/identity-unlocked/id1529010471) and [Spotify](https://open.spotify.com/show/1Y6XBZcVK45QijvV0o7RVs). 

## About Vittorio Bertocci
[Vittorio Bertocci](https://auth0.com/blog/authors/vittorio-bertocci/) is Principal Architect at Auth0 and applies his vast knowledge of the identity industry to Auth0 in all aspects of the company, including internal and external education, product innovation, and customer integration. Prior to Auth0, Bertocci spent 17 years at Microsoft, where he worked on the Azure Active Directory team and focused largely on improving the developer experience. As a published author of four identity books and a highly-trafficked blog: cloudidentity.com, his forward-thinking commentary has enabled him to speak at conferences, such as Identiverse, BUILD, PDC, TechEd, Cloud Identity Summit, and many other industry events around the world.

<include src="asides/AboutAuth0" />

### Media Contacts
Jeana Tahnk<br />
Auth0 Global Communications<br />
[press@auth0.com](mailto:press@auth0.com)<br />
 
Hannah Carroll<br />
Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />


Auth0 Launches Identity, Unlocked: The Identity Podcast for Developers

Brian Campbell joins the show to discuss sender constraint and associated specifications.



### The Overview

On the first episode of _Identity, Unlocked_, host Vittorio Bertocci, Principal Architect at [Auth0](http://www.auth0.com?utm_source=podcast&utm_medium=blog&utm_campaign=identity-unlocked), is joined by Brian Campbell. Brian joins the show to discuss the sender constraint and associated specifications. 
 
The mechanism described by OAuth2 for using the access token to access resources, as defined in the bearer token usage specification ([RFC6750](https://tools.ietf.org/html/rfc6750)), simply entails attaching a token to the request to the API. The approach is extremely simple to implement, but token leaks can have disastrous consequences: nothing stops an attacker from using a stolen bearer token to access a resource successfully. 

"Sender constraint" indicates a series of techniques that bind tokens to a particular sender, for example, by forcing the token to travel on a specific channel or requiring proof of knowledge of a given key. The goal is to guarantee that only the legitimate sender can successfully use a token to access resources, thus making it impossible for an attacker to access a resource using leaked tokens. 

There are two different specifications in the OAuth 2 family offering viable sender constraint capabilities today: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS, [RFC8705](https://tools.ietf.org/html/rfc8705)) and OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html)). 

MTLS is robust and stable, but not easy to implement in various important scenarios. For a while, the identity community worked on an alternative, a set of specifications under the general token binding moniker (main one: [RFC8471](https://tools.ietf.org/html/rfc8471)); however, support from key industry players disappeared or never materialized, making token binding non-viable.

DPoP quickly emerged as an easy to implement an alternative that could fill that gap, and although it is still in draft state, it is already very popular and making quick progress.

Brian touches on all those specs during the episode, walking us through the trajectory that led us to today's situation and taking the time to dig deeper into the trade-offs, strengths, and attention points of the various approaches. The episode concludes with important practical considerations to keep in mind when planning an implementation strategy for the sender constraint in your solutions today.  

Read on for more in-depth information on this episode and make sure to subscribe and join us for the next episode, where [Aaron Parecki](https://twitter.com/aaronpk) (Senior Security Architect) talks about what's new with OAuth2.1.

### Highlights:

In the following, we highlight key passages of the interview. We added some background information here and there to make it easier to follow the conversation if you aren't already familiar with the topic.

**[4:45]** - What is sender constraint and what problem is it trying to solve?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=9506a0f1&embed=true"></iframe> 

The figure below shows a typical OAuth 2 flow for calling an API- a good example to understand how bearer tokens are meant to work.

![Bearer](https://images.ctfassets.net/23aumh6u8s0i/3IJk6fHvBHJcUj5za8yAmt/78444158ad7ab009e2c2a1bddf66b027/1-bearer)

In the first leg of the diagram, a client requests an access token - this might be the redemption of an authorization code, of a refresh token, anything that leads to an access token being issued to the client as shown in step 2.
In this particular example, we are issuing tokens that are digitally signed by the `authorization` server via its private key (other token encodings are possible).

In step 3, the client calls the API by simply attaching the access token to the request (typically by placing it in the authorization HTTP header).

In step 4, the API validates the incoming access token (in this example, that includes validating the signature with the public key associated with the authorization server), and the call succeeds. 

The following diagram shows what happens when a bearer token is leaked.

![BearerAttack](https://images.ctfassets.net/23aumh6u8s0i/5TsCBLxiteQCHodPQYdMhp/3657fc2c592b822f960b90395be69cc0/2-bearerattack)

In step 1, an attacker steals an access token. For the purpose of highlighting the problem with bearer token leaks, it doesn't matter how the leak occurs (the token might be leaked from a cache, a referral header, an HTTPS tunnel termination, erroneously forwarded to a malicious address etc., etc.) as it doesn't change the consequences of the leak.
Once an attacker has the token, all they need to do to access the API successfully is to attach it to an API call - the API will perform the same validation we had observed in the former diagram when the call was originating the legitimate sender. 
This is the key limitation of bearer tokens: everything hinges on not making them fall into the wrong hands, as when that happens, there's no easy recourse.

**[11:35]** - What are the current standards with sender constraint?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=1e5c3b2a&embed=true"></iframe>

The main specifications extending OAuth 2 with sender constraint capabilities are:

* MTLS ([RFC8705](https://tools.ietf.org/html/rfc8705))
* DPoP ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html))
* Token binding ([RFC8471](https://tools.ietf.org/html/rfc8471))

Token binding is mentioned out of exhaustiveness, but it isn't really a viable option as of today. 
For the other ones, we give more details later on in the interview.

**[11:51]** - Brian explains mutual TLS profile for OAuth 2.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=d98141ee&embed=true"></iframe>

Here's a super quick primer to explain how MTLS works in OAuth 2. This leaves out lots of details, so if you are interested, you should consider taking a look at the spec itself ([RFC8705](https://tools.ietf.org/html/rfc8705)).
Please consider the diagram below.

![MTLS](https://images.ctfassets.net/23aumh6u8s0i/3nVuTSuMHCkIm7XS3pyxDw/5a97276eaa4f3a1a8e7f1c45d1a08274/3-mtls)

The client application has access to an X509 certificate, which it uses to perform client TLS authentication (hence proving possession of the corresponding private key) when requesting a token from the authorization server.
The authorization server issues a token containing (or referencing, if other token encoding methods are used) a claim cnf carrying the thumbprint of the X.509 certificate used to establish the channel. 
Important note: the access token is still meant to be signed by the authorization server, and the API is still meant to validate that signature, but we are omitting it in all diagrams from now on for simplicity. 

In step 2, the client establishes a channel with the API/resource server, again using its X509 certificate to establish client TLS. 

In step 3, the API validates the incoming token as usual, and additionally, it verifies that the certificate thumbprint corresponds to the certificate used to establish the TLS channel. If the two matches, the call is considered valid.  

![MTLSAttack](https://images.ctfassets.net/23aumh6u8s0i/479dKTr0VNwPDUT3i8Fwyl/e57676ac4b63edca06a5409ba42d6e3a/4-mtlsattack)

Consider now the case in which an attacker successfully steals a token. The attacker does not have access to the same certificate as the legitimate client; hence it cannot establish a client TLS channel with the API when attempting to use the stolen token - or it has to use a different certificate.
However, the API will easily spot that the certificate thumbprint carried by the cnf claim in the incoming access token does NOT correspond to the certificate used in client TLS authentication by the attacker; hence the API will deny access.

**[15:32]** - Brian explains DPoP. 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=36aff654&embed=true"></iframe>

To help you follow the discussion, here’s a diagram exemplifying how DPoP works. 

![DPOP](https://images.ctfassets.net/23aumh6u8s0i/xrkq0ZMdUIwjiCeuZ6aXf/f333027993663e18e5f714e7d7d43d7f/5-dpop)

The idea is simple: the client uses some keys when requesting a token, those keys are referenced by the access token issued by the authorization server, and the client demonstrates knowledge of the same keys to the resource server when using that access token to call an API. Let's break that down in the steps shown in the diagram.

The client generates a private-public keys pair. It then creates a JWT, called DPoP proof, including in it a claim `jwk`carrying the public key from the pair, an `htu` claim indicating the intended destination of the call (in this case, something like [`https://server.example.com/token`](https://server.example.com/token)), a claim `htm` the HTTP method to be used in the call, and (not shown in the diagram) a `jti` claim (identifier) and an `iat` claim (issuance instant). It then proceeds to digitally sign the JWT with the private key from the generated pair.

In step 1, the client attaches the DPOP proof in a DPOP HTTP header to a token request to the authorization server.

In step 2, the authorization server uses the public key in the `jwk` claim from the DPoP proof to validate its signature, verifying that the sender does indeed have access to the corresponding private key. That done; it issues a new access token (once again, the token signature is omitted, but it is there, just like in the first diagram in this post) and embeds in it a `cnf` claim containing the public key received from the client.

In step 3, the client calls the API. Using the DPoP, the client creates a new DPoP proof, including the same `jwk` with the generated public key, a `htu` with the URL of desired API endpoint (for example, [`https://resource.example.org/protectedresource`](https://resource.example.org/protectedresource)) and `htm`, `jti`, and `iat` claims of the appropriate value. The client then attaches the DPoP proof and the access token to the request to the API.

In step 4, the client validates the incoming access token as it would do in a normal bearer case. In addition to that, it validates the DPoP signature with the `jwk` it carries, validates that the content of the DPoP proof accurately describes the targeted API and thatthe thumbprint of the key embedded in the `cnf` claim in the incoming access token corresponds to the `jwk` in the DPoP proof. If all that checks out, the API has proof that the caller is indeed entitled to use that token and allows the request to succeed.
The failure case here is very similar to the one shown in the MLTS diagram. An attacker stealing a token would not have access to the private key the legitimate client-generated at request time; hence it would not be able to manufacture the appropriate DPoP proof that would convince the API to accept the stolen access token. Bam. Sender constraint!

**[18:42]** - If DPOP blossoms like some anticipate, is there any reason to continue mutual TLS?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=db16444d&embed=true"></iframe>

**[23:23]** - Brian’s opinion on how DPoP can be rolled out.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=dcdf8d37&embed=true"></iframe>

### Links/Resources:

Learn more about [Brian Campbell](https://www.linkedin.com/in/bcampbell)<br />
Brian Campbell on [Twitter](https://twitter.com/__b_c)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
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 />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 1

Join me and our guest identity experts to discuss identity specs and trends from a developer perspective



**TL;DR:** we are launching a podcast in which we interview identity standards experts on the latest trends and specifications, focusing on the concrete impact on development practices.

## How "Identity, Unlocked" was envisioned

Today’s rich internet-powered experiences would not be possible without the widespread adoption of OAuth2 and OpenID Connect standards. By taking care of authentication and authorization in an implementation-independent manner, standards-compliant services and SDKs stops developers from wasting precious cycles reinventing the wheel, freeing time to focus on what they really want to achieve.

Although adding sign-on to web apps and calling APIs using delegated authorization can usually be achieved using SDKs and services, leaving them the grunt work of generating and interpreting standard-compliant messages, it is not always possible to totally ignore the implications that come with choosing this or that particular protocol flavor.

Last year, the OAuth working group at IETF (Internet Engineering Task Force) established that times were finally ripe to abandon the OAuth2 implicit grant as the (begrudgingly) recommended practice for securing API calls originating from single-page apps, favoring the safer authorization code grant, and started the process of updating the specs accordingly. 

The working groups operate transparently; hence news of the initiative rippled outside the cohort of people working on standards, reaching the general developer population. What followed were weeks of confusion and, in some cases, outright panic. Most people had no idea that their apps were using the implicit flow, a detail abstracted away by SDKs, and didn’t know how to react to the news. Was there a new vulnerability in the open that required immediate intervention? Were their customers at risk right now? That wasn’t the case. In the end, as more information and explainers surfaced, the worst reactions were curbed. 

Those reactions are understandable. Specifications are full of nuances that can only be understood in context; they use very precise language that strives to be concise and channel hard-won consensus, which often makes it difficult to discern true intent without having been part of the discussions that led to that particular outcome. No wonder people unfamiliar with the process (and the domain) have to resort to reasoning by soundbites. Even doing one of the many classes available online for getting up to speed with the core specifications (a couple we use to ramp up Auth0 employees are free: [Learn Identity](https://bit.ly/LearnIdentity) and [OpenID Connect Pro Guide](https://bit.ly/OIDCProGuide)) won’t prepare you for fully appreciating the implications of the latest advancements.


![Identity, Unlocked](https://images.ctfassets.net/23aumh6u8s0i/10qlINd02RINycR1iWObwH/6d16992378671652dc029d0227d6ed67/brian_vittorio)
<p align="left"><i>Vittorio and Brian Campbell recording the first episode of <b>Identity, Unlocked</b></i></p>


The fact is, staying on top of identity specifications developments is literally a full-time job: there are folks who do that for a living, and even then, it’s not uncommon to see some degree of specialization (e.g., people being active in the OAuth community but not as much in the OpenID one). The only entities with bandwidth and expertise to tackle that activity are companies and individuals who made identity their career. And yet, the decisions made in those halls affect everyone, as they ripple through the industry and ultimately affect what is achievable in development and experienced by end-users. Wouldn’t it be great if we could find a way to make specification news more accessible to everyone?

While reasoning about the problem, I kept going back to a scene that will be familiar to most identity experts. You are at the bar with a fellow identirati, enjoying a drink after a full day of conference activities, discussing the most interesting sessions of the last few hours. Here’s the key point: if there is someone in the group that’s not an identity expert, every effort will be made to keep the conversation light on jargon and discuss problems in terms they can relate to, keeping the conversation as inclusive as possible; encouraging participation.

The thought went on: what if we’d try to recreate the same dynamic, and make the outcome widely accessible in the form of a podcast? We could just have a chat between strongly opinionated friends who happen to work in the identity specs space, with microphones instead of drinks, and explore important topics - teasing out perspectives and info that are otherwise VERY hard to come by without being a full-time identity person.

I pitched the idea in Auth0 and found enthusiastic support. 

The outcome is **Identity, Unlocked** - a podcast following precisely that format: a chat among friends about identity spec topics, discussed in a format that never loses sight of concrete development applications. 

## What should we expect from the first season

In this first season of Identity, Unlocked I chat with some of the bigwigs of identity specifications - people like Brian Campbell, Dick Hardt, Pamela Dingle, John Bradley, Daniel Fett, Aaron Parecki - covering a wide range of topics that go from the immediately consequential (e.g., OAuth2 Security BCP, OAuth2.1) to the future looking (e.g., GNAP). Those folks are sharp and funny- chatting with them was great fun, and I am convinced you’ll find the result very informative.

We’ll release our first episode on September 14th, chatting with Brian Campbell, exploring sender constraints in general, and DPoP in particular. From then on, we’ll release a new episode every two weeks - for a total of 6 episodes run.

Although there are plenty of instructional initiatives for protocols (e.g., OAuth 101 explainer articles, books, videos, etc.) and many other podcasts tackling identity from the products and trends perspective, we saw an opportunity to bridge the gap between ultra-specialized specification talk and practical application. Let me tell you; it is hard. Some of the topics are so specific that they might remain difficult for some, no matter how much context we tried to provide. With each episode, we’ll post a blog that helps explain some of the more complex topics in more detail.

That’s one more reason for which we are super excited to finally make the podcast available to you - we can’t wait to hear your feedback!

To learn more about **Identity, Unlocked**, visit [identityunlocked.com](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/025d70b9?utm_source=podcast&utm_medium=pr&utm_campaign=identity-unlocked), and subscribe to the latest podcast updates and episodes on [Apple Podcasts](https://apple.co/3lDPPAm) and [Spotify](https://spoti.fi/3gzSiI5). 

<include src="asides/AboutAuth0" />


Identity, Unlocked: A Podcast For Developers

667b1c82b6cc2241ff176d50c65da603?s=200 avatar

667b1c82b6cc2241ff176d50c65da603?s=200

Guest Author

Eugene Kogan

How to prevent criminals to mess with your accounts



Yes, definitely. It’s happened to a number of people I work with.

Imagine you’re walking down the street, checking Slack or Facebook, and someone on a bike rides by and grabs your phone. Guess what, your phone is unlocked and ready for the thief to start using it. The same thing can happen in a bar, the subway, or any other crowded place. Even Scotland Yard has started [using](http://www.bbc.com/news/uk-38183819) this technique (but that’s another matter).

![Getting robbed while phone is unlocked](https://images.ctfassets.net/23aumh6u8s0i/4Kr00xYZ8Z4iCkFPziAi6y/7f5e7c11ed2ede9a715a1ba481859d37/getting-robbed)

The average iPhone thief doesn’t care about your data, he just wants to wipe the phone so he can resell it. This kind of crime is especially prevalent in countries like [Argentina](http://money.cnn.com/2016/09/14/technology/argentina-iphone-black-market/), where there’s a large black market for Apple products. You might be thinking that the thief still needs to disable Find My iPhone to release Apple’s [Activation Lock](https://support.apple.com/en-us/HT201365). That’s true, but if the phone itself is already unlocked, all he needs is your iCloud password.

Do you get your email on your phone? Is it the same email address that’s tied to your iCloud account? Well, guess where iCloud password reset emails used to go? Before a recent update to iOS, it was possible to reset someone’s iCloud password directly from their unlocked phone, simply by virtue having access to their email account. Even if you use Apple’s [two-factor authentication](https://support.apple.com/en-us/HT204915) (which you absolutely should), that works over SMS or push notifications, which also go to your phone.

Previous, there was nothing blocking a thief from stealing your phone while it was in use (and unlocked), resetting your iCloud password via your email account, disabling Find My iPhone, and finally wiping it to be resold. Thankfully, Apple appears to have quietly fixed this loophole by making it more difficult to reset an iCloud password. If you attempt it from your phone (even via Safari), it will ask you for your unlock PIN.

I used to recommend taking an additional precaution to mitigate this risk, but it’s not really necessary anymore (although it can’t hurt). If you follow these steps, the iCloud account settings will be completely unavailable until you disable “Restrictions” with an extra PIN that you’ll set below. Go to *Settings > General > Restrictions > Enable Restrictions > [create a PIN, enter it twice] > Accounts > Don’t Allow Changes*

Now that Apple has added the necessary security checks to the iCloud password reset process, my recommendations are simpler: enable two-factor authentication for iCloud, and choose a hard to guess, 6-digit (or longer) PIN on your iPhone. With Touch ID, you rarely have to type it anyway.

![Apple's two factor authentication](https://images.ctfassets.net/23aumh6u8s0i/1JZgMtXTm0TfSnGCab8MWK/c2a81630672de5ada598f83c417b2d2b/apple-2-factor-auth)

**Kudos to Apple for making this improvement. I believe it will help keep people safer by discouraging iPhone muggings.**

Now, if you’re a bit more paranoid and want to really limit what someone can access if they snatch your phone while you’re in the middle of using it, there is one more thing you can do.

An [engineer](https://twitter.com/radekk) on my team at Auth0 told me about [Guided Access](https://support.apple.com/en-us/HT202612), an iOS feature that lets you temporarily restrict the phone to a single app, and can even limit the actions available to the user within an app. With Guided Access configured (*Settings > General > Accessibility > Guided Access*), you can press the home button three times to enable it at any time, within any app. Once it’s on, you’ll need the Guided Access PIN or Touch ID to exit the app. It’s that easy.

Imagine you’re reading the news on your iPhone on the subway. You can quickly enable Guided Access, and lock it down to that one app only. Then even if someone grabs your unlocked phone, they’ll be stuck in the news app forever! (No one wants to read the news for too long nowadays.) Sure, the thief can always power it off, but then the phone will be really locked and essentially useless to them, even for reselling.

Guided Access is intended for situations like when parents let their kids play with their iPhones (or iPads), but it’s actually quite powerful. You could even use it if you think Scotland Yard might be after you…

"unlocked"