Supported OpenID Connect Flows

In WFP we have two types of Client-side applications (CSA), Single Page Applications (SPA) and Mobile Applications. Each of the two application domains requires specific auhotrizations models and patterns. They both share some essential rules:

1. They cannot store the client’s password completely securely on the client-side; and
2. They cannot store the access tokens completely securely on the client-side.

In SPAs, the client password and access tokens have to be stored in the user’s browser; in mobile native applications, they have to be stored in memory that is accessible by the application. Since both these kinds of applications store the client password and access tokens outside the control perimeter of the application, we cannot consider the client password or access token as entirely confidential. There are some implementation flows that we decided to support with the CIAM:

• Authorization Code Grant;
• Authorization Code Grant with PKCE Extension;

Authorization Code Grant

Authorization code flow is the most flexible of the supported authorization flows and is the recommended method of obtaining an access token for the API. This authorization flow is best suited to applications that have access to secure, private storage such as web applications deployed on a server.

Auhtorization Code Grant with PKCE Extension

The Authorization Code Flow + PKCE is an OpenId Connect flow specifically designed to authenticate native or mobile application users.

This flow is considered best practice when using Single Page Apps (SPA) or Mobile Apps.

PKCE, pronounced “pixy” is an acronym for Proof Key for Code Exchange. The key difference between the PKCE flow and the standard Authorization Code flow is users aren’t required to provide a client_secret. PKCE reduces security risks for native apps, as embedded secrets aren’t required in source code, which limits exposure to reverse engineering.

References

Authorization Code Flow with Proof Key for Code Exchange (PKCE)