see 2021
Session / Architecture & Standards

OAuth2.0/OIDC Journey at a Global Financial Organization

Tuesday, June 22
2:05pm - 2:30pm MDT

At a global financial organization that I work for, we have now successfully rolled out the OAuth2.0/OIDC plant and the journey has been filled with learnings and experiences worth sharing with others. This has definitely been far from a smooth journey, advocating the use of open standards and encouraging moving away from home grown solutions. This discussion can prove helpful to others embarking on a similar journey.

The firm’s initial deployment of OAuth and OpenID Connect will only support OIDC related scopes( i.e. openid, profile, address, email, and phone) , but will not support the inclusion of authorization information via ‘scopes’ . This informed decision has been made considering the effort required to support scopes for a wide variety of applications at a large scale enterprise level. This feature will be made available in the future releases after considerable research and development has been put in to make the process efficient and scalable.

The clients are allowed to only choose one among Authorization code grant, refresh grant in support of Authorization Code grant, Authorization code grant with PKCE , Client Credentials grant and Device Authorization grant. A conscious decision has been made to NOT support Resource Owner Password Credentials grant type.  With Client Credentials grant type, OAuth2 client by itself becomes an identity which can have implications on reporting and auditing. Policies have been put in place to avoid improper management of clients that can lead to unclear ownership and inability to track client credentials.

For a variety of flows, an OAuth2 Client must authenticate itself with an OAuth2 Authorization Server. Typical means of client authentication include a shared secretclient certificates/mutual TLS, and recently a private key JWT. With a shared secret, there is a large operational burden and a security risk as secret sharing among parties is difficult to do right. Mutual TLS setups are brittle and burdensome from an operational perspective. Hence we advocate the use of private key JWT for client authentication.

Considerable effort has been put into formulating policies around the available claims in the id tokens and access tokens. As the firm offers a wide range of identity stores, it becomes extremely important to emit identities in a consistent and repeatable way. The aim of these policies is to convey identity to applications in a manner agnostic to identity stores and to decouple applications from authentication mechanisms, yet preserve authentication context.

OpenID Tokens, per specification, are in JWT format. Access tokens can either be in JWT format or can be an opaque reference token. The pros and cons of different formats were investigated and accordingly policies were formulated for online vs offline access token validation. Similarly many other aspects of the OAuth2.0/OIDC have been explored and appropriate security policies have been agreed upon for efficient deployment of these standards that can cater to a wide variety of demands from the clients.