Cybersecurity Advocate: Meet Rifaat Shekh-Yusef

Organizations today face increasingly diverse and sophisticated cyber threats. This work is bigger than any one entity; it forms part of a collaborative global initiative to make the internet a safer place. For Cyber Security Awareness Month, we’re going behind the scenes with some of Okta’s Cyber Security Advocates, a talented group of professionals from diverse backgrounds, to learn their perspectives on the field and how they got here. 

Rifaat Shekh-Yusef, Group Product Manager- IAM Standards at Okta (Auth0 Product Unit), has more than two decades of experience beginning as a software engineer and moving to architectural roles while also helping develop identity based architectural standards. He is a chair of the OAuth WG and either with himself or others has 9 issued patents.

Jenny O’Brien, Senior Manager, Business Content at Okta, sat down with Rifaat  to discuss his work helping to develop protocols, what interoperability really means for devs, and how evolving specifications helps mitigate cyber attacks

Jenny: Tell us about how royalty-free identity icons led you to Okta.

Rifaat: It’s a funny story. I knew Vittorio [Bertocci] from the IETF, and one time he had a presentation and he used some cool icons, and he mentioned that they are free icons from Auth0.

I visited the Auth0 site looking for these icons and started poking around to learn more about Auth0, and was intrigued by their focus on IAM and their extensive use of OAuth. I then noticed that Auth0 had an open position for a product manager for the Protocols team, so I discussed this with Vittorio, and he encouraged me to apply after the high praises he gave to the company and its culture.

Jenny: Did you know you wanted to be a product manager when you started out or did the goal evolve over time? 

Rifaat: During my last project at my previous employer, I was the lead architect for a major cloud-based service to automate the deployment of telephony devices. Unfortunately, most of the time we did not have a product manager that was assigned to this product, so essentially I was the lead architect and the de facto product manager. That was the reason I got interested in product management roles, and the Auth0 role was my first official product manager role.

Jenny: The Web Authorization Protocol (OAuth) at the IETF (Internet Engineering Task Force) focuses on increasing security for third-party access including interoperability. As the chair of that working group, how are you defining true interoperability?

RIfaat: The OAuth protocol is an authorization framework that keeps on evolving to address the market needs based on real deployment experience.

True interoperability provides consistent interfaces across all OAuth entities that play the same role, which allows each OAuth entity to implement their side once and know that they are guaranteed the ability to properly integrate with the other OAuth entities. 

To achieve true interoperability, some OAuth profiles, e.g. FAPI, have been created to make sure that the various OAuth entities have a clear understanding of what needs to be implemented to allow for a proper integration.

Jenny: What are the top 3 dev-focused challenges to interoperability?

RIfaat:The OAuth framework is a complex and ever evolving set of specifications. Because of that, there are multiple challenges for developers:

1. Keeping up to date on the latest OAuth specifications is a real challenge.
2. The OAuth specifications sometimes define a number of ways to implement the same functionality; for example, client authentication can be achieved through shared secret, private key jwt, or MTLS. The developer needs to make sure to implement the best option that addresses their needs.
3. Security is always a major challenge, because what worked until today might not be good enough going forward. This means that OAuth solutions must always try to keep up with the latest best security practices.

Jenny: For the business decision maker, what kinds of scenarios will interoperability enable? 

Rifaat: The industry used the OAuth protocol as a core building block for a variety of solutions, and created an extensive ecosystem of solutions on top of the OAuth framework. 

The OpenID Foundation extended the OAuth framework and defined an identity layer on top of OAuth, called the OpenID Connect. The OpenID Foundation also defined a number of profiles to address the needs of various verticals. For example, FAPI profiles were created, initially to address the stringent security needs of the financial services, which could also be used by many other verticals that need such security capabilities.

OpenBanking initiatives around the world used these FAPI profiles to define a variety of solutions to address the specific needs of the financial sector and to comply with regulations like PSD2 in Europe. For example, OpenBanking UK, CDR in Australia, Open Banking Brazil, FDX in US and Canada, etc.

These FAPI profiles are now being used or considered by other verticals, like telecom, energy, etc.

Jenny: Can you outline how the protocol will bridge legacy identity infrastructure (like SAML) with OAuth?

Rifaat: OAuth is an authorization framework, while SAML is an authentication protocol that was designed initially to address the workforce use case, like SSO.

To address the authentication use cases, the OpenID Foundation created the OpenID Connect that is an identity layer on top of OAuth. The OAuth WG also created a SAML Profile specification that defines the use of SAML assertions to request OAuth tokens and for client authentication.

Jenny: How will this protocol change how devs work with tokens?

Rifaat: Initially the OAuth 2.0 protocol defined bearer tokens, which were easy to handle, because it does not require the sender of the token to prove anything beyond that it is holding the token to be able to get access to the services. This meant that if a token was leaked, it was easy for anyone to use that token to get access to these resources.

The OAuth WG has been working on a new method to define sender-constraint tokens, called Demonstrating Proof-of-Possession at the Application Layer (DPoP), where the sender of the token must prove that they are the right owner of the token. This mechanism will make it much harder to use such a token by an unauthorized entity, even if the token is leaked.

Jenny: Will this protocol influence how devs handle financial grade authentication? How and why?

Rifaat: The OpenID Foundation defined a set of profiles that is meant to address the stringent security requirements of the financial industry. These profiles are based heavily on new mechanisms developed by the OAuth WG at the IETF, like JWT-Secured Authorization Request (JAR), Pushed Authorization Requests (PAR), Rich Authorization Requests (RAR), and Step-up Authentication. 

Jenny: How will these new specifications help mitigate security attacks?

Rifaat: JAR is used to secure sending authorization requests parameter to the authorization server through the user agent, e.g., browser, by sending these parameters in signed or/and encrypted JWT. 

PAR is a mechanism used to avoid sending the authorization request parameters through the browser, and instead, send the details directly to the authorization server and getting back a reference that will be sent to the authorization server through the browser.

RAR will be used to provide fine-grained authorization details that will be useful for dynamic linking use cases where a user gets notifications to their mobile app to approve sensitive transactions.

Step-up authentication is a mechanism that allows resource servers to request a specific level of authentication to allow the client access to a specific resource.

All these new mechanisms will dramatically improve the security of any OAuth deployment.

Jenny: Tell us more about how protocols are developed.

Rifaat: IETF RFCs start their lives mostly as an individual draft that holds the ideas and opinions of the authors, not the IETF. If the authors are able to convince the IETF working group that they have an idea or a solution worth pursuing, then the working group will adopt the document as a working group draft. At this point, the document holds the opinion of the working group, and any changes to the document must be approved by the working group. This process could take a very long time. After that is done, and the working group is happy with the document, the draft will be submitted by the working group chair to the Internet Engineering Steering Group (IESG) and the wider IETF, which will review the draft and provide their feedback, which could result in more updates to the draft. After that is done and the document is approved by the IESG, the document will be sent to the RFC Editor for final editorial review, and later publication. 

Jenny: What do you wish devs knew about how protocols are created?

Rifaat: During the development of IETF drafts, there are typically a number of implementations that are going on at the same time. Many times, the draft gets updated based on the experience and feedback provided by the engineers working on these developments. I would like to encourage our engineers to help with these efforts, because it allows us to be at the forefront of the development of these specifications and provides us with the chance to influence the direction of these documents before they are published.

Jenny: Where do you see cybersecurity trending in 2023?

Rifaat: The industry has been discussing the Zero Trust concept for some time now, but we see great progress towards this goal that I expect will accelerate in the near future, and IAM is a critical part of that effort.

Traditional trust models relied on breaking the networks into different zones, and assumed that the network inside the data center is a trusted network. That proved to be a flawed assumption, because as soon as an attacker was able to compromise one entity in the network, the attacker had access to the rest of the data center entities.

Zero-Trust is a trust model where every entity, e.g., user, application, device, is by default not a trusted entity, until it proves its identity. Another fundamental principle of Zero Trust is the least privilege principle, which dictates that each entity must be provided with the minimal permission it needs to perform its function properly. 

There is still more work to be done on both of these aspects of Zero Trust.

Visit the Okta and Auth0 careers pages to learn how to start your own career in cyber security, and explore the field through our Cyber Security Awareness Month blog series.